7559 lines
311 KiB
HTML
7559 lines
311 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="robots" content="index,follow" />
|
|
<meta name="creator" content="rfcmarkup version 1.111" />
|
|
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
|
|
<meta name="DC.Relation.Replaces" content="rfc5414" />
|
|
<meta name="DC.Identifier" content="urn:ietf:rfc:5415" />
|
|
<meta name="DC.Date.Issued" content="March, 2009" />
|
|
<meta name="DC.Creator" content="Stanley, Dorothy" />
|
|
<meta name="DC.Creator" content="Calhoun, Pat" />
|
|
<meta name="DC.Creator" content="Montemurro, Michael" />
|
|
<meta name="DC.Description.Abstract" content="This specification defines the Control And Provisioning of Wireless
|
|
Access Points (CAPWAP) Protocol, meeting the objectives defined by the
|
|
CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to
|
|
be flexible, allowing it to be used for a variety of wireless
|
|
technologies. This document describes the base CAPWAP protocol, while
|
|
separate binding extensions will enable its use with additional
|
|
wireless technologies. [STANDARDS-TRACK]" />
|
|
<meta name="DC.Title" content="Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification" />
|
|
|
|
<link rel="icon" href="/images/id.png" type="image/png" />
|
|
<link rel="shortcut icon" href="/images/id.png" type="image/png" />
|
|
<title>draft-ietf-capwap-protocol-specification-07 - Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification</title>
|
|
|
|
|
|
<style type="text/css">
|
|
body {
|
|
margin: 0px 8px;
|
|
font-size: 1em;
|
|
}
|
|
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
|
|
font-weight: bold;
|
|
line-height: 0pt;
|
|
display: inline;
|
|
white-space: pre;
|
|
font-family: monospace;
|
|
font-size: 1em;
|
|
font-weight: bold;
|
|
}
|
|
pre {
|
|
font-size: 1em;
|
|
margin-top: 0px;
|
|
margin-bottom: 0px;
|
|
}
|
|
.pre {
|
|
white-space: pre;
|
|
font-family: monospace;
|
|
}
|
|
.header{
|
|
font-weight: bold;
|
|
}
|
|
.newpage {
|
|
page-break-before: always;
|
|
}
|
|
.invisible {
|
|
text-decoration: none;
|
|
color: white;
|
|
}
|
|
a.selflink {
|
|
color: black;
|
|
text-decoration: none;
|
|
}
|
|
@media print {
|
|
body {
|
|
font-family: monospace;
|
|
font-size: 10.5pt;
|
|
}
|
|
h1, h2, h3, h4, h5, h6 {
|
|
font-size: 1em;
|
|
}
|
|
|
|
a:link, a:visited {
|
|
color: inherit;
|
|
text-decoration: none;
|
|
}
|
|
.noprint {
|
|
display: none;
|
|
}
|
|
}
|
|
@media screen {
|
|
.grey, .grey a:link, .grey a:visited {
|
|
color: #777;
|
|
}
|
|
.docinfo {
|
|
background-color: #EEE;
|
|
}
|
|
.top {
|
|
border-top: 7px solid #EEE;
|
|
}
|
|
.bgwhite { background-color: white; }
|
|
.bgred { background-color: #F44; }
|
|
.bggrey { background-color: #666; }
|
|
.bgbrown { background-color: #840; }
|
|
.bgorange { background-color: #FA0; }
|
|
.bgyellow { background-color: #EE0; }
|
|
.bgmagenta{ background-color: #F4F; }
|
|
.bgblue { background-color: #66F; }
|
|
.bgcyan { background-color: #4DD; }
|
|
.bggreen { background-color: #4F4; }
|
|
|
|
.legend { font-size: 90%; }
|
|
.cplate { font-size: 70%; border: solid grey 1px; }
|
|
}
|
|
</style>
|
|
<!--[if IE]>
|
|
<style>
|
|
body {
|
|
font-size: 13px;
|
|
margin: 10px 10px;
|
|
}
|
|
</style>
|
|
<![endif]-->
|
|
|
|
<script type="text/javascript"><!--
|
|
function addHeaderTags() {
|
|
var spans = document.getElementsByTagName("span");
|
|
for (var i=0; i < spans.length; i++) {
|
|
var elem = spans[i];
|
|
if (elem) {
|
|
var level = elem.getAttribute("class");
|
|
if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
|
|
elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
|
|
}
|
|
}
|
|
}
|
|
}
|
|
var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </span></td></tr> </table>";
|
|
function showElem(id) {
|
|
var elem = document.getElementById(id);
|
|
elem.innerHTML = eval(id+"_html");
|
|
elem.style.visibility='visible';
|
|
}
|
|
function hideElem(id) {
|
|
var elem = document.getElementById(id);
|
|
elem.style.visibility='hidden';
|
|
elem.innerHTML = "";
|
|
}
|
|
// -->
|
|
</script>
|
|
</head>
|
|
<body onload="addHeaderTags()">
|
|
<div style="height: 13px;">
|
|
<div onmouseover="this.style.cursor='pointer';"
|
|
onclick="showElem('legend');"
|
|
onmouseout="hideElem('legend')"
|
|
style="height: 6px; position: absolute;"
|
|
class="pre noprint docinfo bgred"
|
|
title="Click for colour legend." > </div>
|
|
<div id="legend"
|
|
class="docinfo noprint pre legend"
|
|
style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; "
|
|
onmouseover="showElem('legend');"
|
|
onmouseout="hideElem('legend');">
|
|
</div>
|
|
</div>
|
|
<span class="pre noprint docinfo top">[<a href="../html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/id/draft-ietf-capwap-protocol-specification-07.txt" title="Plaintext version of this document">txt</a>|<a href="/pdf/draft-ietf-capwap-protocol-specification-07.txt" title="PDF version of this document">pdf</a>] [<a href='https://datatracker.ietf.org/doc/draft-ietf-capwap-protocol-specification' title='IESG Datatracker information for this document'>Tracker</a>] [<a href="../wg/capwap" title="The working group handling this document">WG</a>] [<a href="mailto:draft-ietf-capwap-protocol-specification@tools.ietf.org?subject=draft-ietf-capwap-protocol-specification%20" title="Send email to the document authors">Email</a>] [<a href="/rfcdiff?difftype=--hwdiff&url2=draft-ietf-capwap-protocol-specification-07.txt" title="Inline diff (wdiff)">Diff1</a>] [<a href="/rfcdiff?url2=draft-ietf-capwap-protocol-specification-07.txt" title="Side-by-side diff">Diff2</a>] [<a href="/idnits?url=https://tools.ietf.org/id/draft-ietf-capwap-protocol-specification-07.txt" title="Run an idnits check of this document">Nits</a>] [<a href="https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-capwap-protocol-specification" title="IPR disclosures related to this document">IPR</a>] </span><br />
|
|
<span class="pre noprint docinfo"> </span><br />
|
|
<span class="pre noprint docinfo">Versions: <a href="./draft-ietf-capwap-protocol-specification-00">00</a> <a href="./draft-ietf-capwap-protocol-specification-01">01</a> <a href="./draft-ietf-capwap-protocol-specification-02">02</a> <a href="./draft-ietf-capwap-protocol-specification-03">03</a> <a href="./draft-ietf-capwap-protocol-specification-04">04</a> <a href="./draft-ietf-capwap-protocol-specification-05">05</a> <a href="./draft-ietf-capwap-protocol-specification-06">06</a> <a href="./draft-ietf-capwap-protocol-specification-07">07</a> <a href="./draft-ietf-capwap-protocol-specification-08">08</a> <a href="./draft-ietf-capwap-protocol-specification-09">09</a> <a href="./draft-ietf-capwap-protocol-specification-10">10</a> <a href="./draft-ietf-capwap-protocol-specification-11">11</a>
|
|
<a href="./draft-ietf-capwap-protocol-specification-12">12</a> <a href="./draft-ietf-capwap-protocol-specification-13">13</a> <a href="./draft-ietf-capwap-protocol-specification-14">14</a> <a href="./draft-ietf-capwap-protocol-specification-15">15</a> <a href="./rfc5415">RFC 5415</a> </span><br />
|
|
<span class="pre noprint docinfo"> </span><br />
|
|
<pre>
|
|
Network Working Group P. Calhoun, Editor
|
|
Internet-Draft Cisco Systems, Inc.
|
|
Expires: December 13, 2007 M. Montemurro, Editor
|
|
Research In Motion
|
|
D. Stanley, Editor
|
|
Aruba Networks
|
|
June 11, 2007
|
|
|
|
|
|
<span class="h1">CAPWAP Protocol Specification</span>
|
|
<span class="h1">draft-ietf-capwap-protocol-specification-07</span>
|
|
|
|
Status of this Memo
|
|
|
|
By submitting this Internet-Draft, each author represents that any
|
|
applicable patent or other IPR claims of which he or she is aware
|
|
have been or will be disclosed, and any of which he or she becomes
|
|
aware will be disclosed, in accordance with <a href="./bcp79#section-6">Section 6 of BCP 79</a>.
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering
|
|
Task Force (IETF), its areas, and its working groups. Note that
|
|
other groups may also distribute working documents as Internet-
|
|
Drafts.
|
|
|
|
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."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>.
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
|
|
|
|
This Internet-Draft will expire on December 13, 2007.
|
|
|
|
Copyright Notice
|
|
|
|
Copyright (C) The IETF Trust (2007).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 1]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Abstract
|
|
|
|
This specification defines the Control And Provisioning of Wireless
|
|
Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF
|
|
CAPWAP working group protocol requirements. The CAPWAP protocol is
|
|
designed to be flexible, allowing it to be used for a variety of
|
|
wireless technologies. This document describes the base CAPWAP
|
|
protocol. The CAPWAP protocol binding which defines extensions for
|
|
use with the IEEE 802.11 wireless LAN protocol is available in [<a href="#ref-12" title=""CAPWAP Protocol Binding for IEEE 802.11"">12</a>].
|
|
Extensions are expected to be defined to enable use of the CAPWAP
|
|
protocol with additional wireless technologies.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 2]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</span>
|
|
|
|
This document describes the CAPWAP Protocol, a standard,
|
|
interoperable protocol which enables an Access Controller (AC) to
|
|
manage a collection of Wireless Termination Points (WTPs). The
|
|
CAPWAP protocol is defined to be independent of layer 2 technology.
|
|
|
|
The emergence of centralized IEEE 802.11 Wireless Local Area Network
|
|
(WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by
|
|
an Access Controller (AC) suggested that a standards based,
|
|
interoperable protocol could radically simplify the deployment and
|
|
management of wireless networks. WTPs require a set of dynamic
|
|
management and control functions related to their primary task of
|
|
connecting the wireless and wired mediums. Traditional protocols for
|
|
managing WTPs are either manual static configuration via HTTP,
|
|
proprietary Layer 2 specific or non-existent (if the WTPs are self-
|
|
contained). An IEEE 802.11 binding is defined in [<a href="#ref-12" title=""CAPWAP Protocol Binding for IEEE 802.11"">12</a>] to support use
|
|
of the CAPWAP protocol with IEEE 802.11 WLAN networks.
|
|
|
|
CAPWAP assumes a network configuration consisting of multiple WTPs
|
|
communicating via the Internet Protocol (IP) to an AC. WTPs are
|
|
viewed as remote RF interfaces controlled by the AC. The CAPWAP
|
|
protocol supports two modes of operation: Split and Local MAC. In
|
|
Split MAC mode all L2 wireless data and management frames are
|
|
encapsulated via the CAPWAP protocol and exchanged between the AC and
|
|
the WTP. As shown in Figure 1, the wireless frames received from a
|
|
mobile device, which is referred to in this specification as a
|
|
Station (STA), are directly encapsulated by the WTP and forwarded to
|
|
the AC.
|
|
|
|
+-+ wireless frames +-+
|
|
| |--------------------------------| |
|
|
| | +-+ | |
|
|
| |--------------| |---------------| |
|
|
| |wireless PHY/ | | CAPWAP | |
|
|
| | MAC sublayer | | | |
|
|
+-+ +-+ +-+
|
|
STA WTP AC
|
|
|
|
Figure 1: Representative CAPWAP Architecture for Split MAC
|
|
|
|
The Local MAC mode of operation allows for the data frames to be
|
|
either locally bridged, or tunneled as 802.3 frames. The latter
|
|
implies that the WTP performs the 802 bridging function. In either
|
|
case the L2 wireless management frames are processed locally by the
|
|
WTP, and then forwarded to the AC. Figure 2 shows the Local MAC
|
|
mode, in which a station transmits a wireless frame which is
|
|
encapsulated in an 802.3 frame and forwarded to the AC.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 3]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
+-+wireless frames +-+ 802.3 frames +-+
|
|
| |----------------| |--------------| |
|
|
| | | | | |
|
|
| |----------------| |--------------| |
|
|
| |wireless PHY/ | | CAPWAP | |
|
|
| | MAC sublayer | | | |
|
|
+-+ +-+ +-+
|
|
STA WTP AC
|
|
|
|
Figure 2: Representative CAPWAP Architecture for Local MAC
|
|
|
|
Provisioning WTPs with security credentials, and managing which WTPs
|
|
are authorized to provide service are traditionally handled by
|
|
proprietary solutions. Allowing these functions to be performed from
|
|
a centralized AC in an interoperable fashion increases manageability
|
|
and allows network operators to more tightly control their wireless
|
|
network infrastructure.
|
|
|
|
<span class="h3"><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Goals</span>
|
|
|
|
The goals for the CAPWAP protocol are listed below:
|
|
|
|
1. To centralize the authentication and policy enforcement functions
|
|
for a wireless network. The AC may also provide centralized
|
|
bridging, forwarding, and encryption of user traffic.
|
|
Centralization of these functions will enable reduced cost and
|
|
higher efficiency by applying the capabilities of network
|
|
processing silicon to the wireless network, as in wired LANs.
|
|
|
|
2. To enable shifting of the higher level protocol processing from
|
|
the WTP. This leaves the time critical applications of wireless
|
|
control and access in the WTP, making efficient use of the
|
|
computing power available in WTPs which are the subject to severe
|
|
cost pressure.
|
|
|
|
3. To provide a generic encapsulation and transport mechanism,
|
|
enabling the CAPWAP protocol to be applied to many access point
|
|
types in the future, via a specific wireless binding.
|
|
|
|
The CAPWAP protocol concerns itself solely with the interface between
|
|
the WTP and the AC. Inter-AC and station-to AC-communication are
|
|
strictly outside the scope of this document.
|
|
|
|
<span class="h3"><a class="selflink" name="section-1.2" href="#section-1.2">1.2</a>. Conventions used in this document</span>
|
|
|
|
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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 4]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-1.3" href="#section-1.3">1.3</a>. Contributing Authors</span>
|
|
|
|
This section lists and acknowledges the authors of significant text
|
|
and concepts included in this specification.
|
|
|
|
The CAPWAP Working Group selected the Lightweight Access Point
|
|
Protocol (LWAPP) [add reference, when available] to be used as the
|
|
basis of the CAPWAP protocol specification. The following people are
|
|
authors of the LWAPP document:
|
|
|
|
Bob O'Hara, Cisco Systems, Inc.
|
|
170 West Tasman Drive, San Jose, CA 95134
|
|
Phone: +1 408-853-5513, Email: bob.ohara@cisco.com
|
|
|
|
Pat Calhoun, Cisco Systems, Inc.
|
|
170 West Tasman Drive, San Jose, CA 95134
|
|
Phone: +1 408-853-5269, Email: pcalhoun@cisco.com
|
|
|
|
Rohit Suri, Cisco Systems, Inc.
|
|
170 West Tasman Drive, San Jose, CA 95134
|
|
Phone: +1 408-853-5548, Email: rsuri@cisco.com
|
|
|
|
Nancy Cam Winget, Cisco Systems, Inc.
|
|
170 West Tasman Drive, San Jose, CA 95134
|
|
Phone: +1 408-853-0532, Email: ncamwing@cisco.com
|
|
|
|
Scott Kelly, Aruba Networks
|
|
1322 Crossman Ave, Sunnyvale, CA 94089
|
|
Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
|
|
|
|
Michael Glenn Williams, Nokia, Inc.
|
|
313 Fairchild Drive, Mountain View, CA 94043
|
|
Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com
|
|
|
|
Sue Hares, Nexthop Technologies, Inc.
|
|
825 Victors Way, Suite 100, Ann Arbor, MI 48108
|
|
Phone: +1 734 222 1610, Email: shares@nexthop.com
|
|
|
|
DTLS is used as the security solution for the CAPWAP protocol. The
|
|
following people are authors of significant DTLS-related text
|
|
included in this document:
|
|
|
|
Scott Kelly, Aruba Networks
|
|
1322 Crossman Ave, Sunnyvale, CA 94089
|
|
Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
|
|
|
|
Eric Rescorla, Network Resonance
|
|
2483 El Camino Real, #212,Palo Alto CA, 94303
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 5]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Email: ekr@networkresonance.com
|
|
|
|
The concept of using DTLS to secure the CAPWAP protocol was part of
|
|
the Secure Light Access Point Protocol (SLAPP) proposal [add
|
|
reference when available]. The following people are authors of the
|
|
SLAPP proposal:
|
|
|
|
Partha Narasimhan, Aruba Networks
|
|
1322 Crossman Ave, Sunnyvale, CA 94089
|
|
Phone: +1 408-480-4716, Email: partha@arubanetworks.com
|
|
|
|
Dan Harkins, Tropos Networks
|
|
555 Del Rey Avenue, Sunnyvale, CA, 95085
|
|
Phone: +1 408 470 7372, Email: dharkins@tropos.com
|
|
|
|
Subbu Ponnuswamy, Aruba Networks
|
|
1322 Crossman Ave, Sunnyvale, CA 94089
|
|
Phone: +1 408-754-1213, Email: subbu@arubanetworks.com
|
|
|
|
|
|
The following individuals contributed significant security related
|
|
text to the draft:
|
|
|
|
T. Charles Clancy, Laboratory for Telecommunications Sciences,
|
|
8080 Greenmead Drive, College Park, MD 20740
|
|
Phone: +1 240-373-5069, Email: clancy@ltsnet.net
|
|
|
|
Scott Kelly, Aruba Networks
|
|
1322 Crossman Ave, Sunnyvale, CA 94089
|
|
Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
|
|
|
|
<span class="h3"><a class="selflink" name="section-1.4" href="#section-1.4">1.4</a>. Terminology</span>
|
|
|
|
Access Controller (AC): The network entity that provides WTPs access
|
|
to the network infrastructure in the data plane, control plane,
|
|
management plane, or a combination therein.
|
|
|
|
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.
|
|
|
|
Station (STA): A device that contains an IEEE 802.11 conformant
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 6]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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 PHY to transmit and receive
|
|
station traffic for wireless access networks.
|
|
|
|
This document uses additional terminology defined in [<a href="#ref-15" title=""Mobility Related Terminology"">15</a>].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 7]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-2" href="#section-2">2</a>. Protocol Overview</span>
|
|
|
|
The CAPWAP protocol is a generic protocol defining AC and WTP control
|
|
and data plane communication via a CAPWAP protocol transport
|
|
mechanism. CAPWAP control messages, and optionally CAPWAP data
|
|
messages, are secured using Datagram Transport Layer Security (DTLS)
|
|
[<a href="#ref-7" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">7</a>]. DTLS is a standards-track IETF protocol based upon TLS. The
|
|
underlying security-related protocol mechanisms of TLS have been
|
|
successfully deployed for many years.
|
|
|
|
The CAPWAP protocol Transport layer carries two types of payload,
|
|
CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data
|
|
messages encapsulate forwarded wireless frames. CAPWAP protocol
|
|
Control messages are management messages exchanged between a WTP and
|
|
an AC. The CAPWAP Data and Control packets are sent over separate
|
|
UDP ports. Since both data and control packets can exceed the
|
|
Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data
|
|
or control message can be fragmented. The fragmentation behavior is
|
|
defined in <a href="#section-3">Section 3</a>.
|
|
|
|
The CAPWAP Protocol begins with a discovery phase. The WTPs send a
|
|
Discovery Request message, causing any Access Controller (AC)
|
|
receiving the message to respond with a Discovery Response message.
|
|
From the Discovery Response messages received, a WTP selects an AC
|
|
with which to establish a secure DTLS session. CAPWAP protocol
|
|
messages will be fragmented to the maximum length discovered to be
|
|
supported by the network.
|
|
|
|
Once the WTP and the AC have completed DTLS session establishment, a
|
|
configuration exchange occurs in which both devices agree on version
|
|
information. During this exchange the WTP may receive provisioning
|
|
settings. The WTP is then enabled for operation.
|
|
|
|
When the WTP and AC have completed the version and provision exchange
|
|
and the WTP is enabled, the CAPWAP protocol is used to encapsulate
|
|
the wireless data frames sent between the WTP and AC. The CAPWAP
|
|
protocol will fragment the L2 frames if the size of the encapsulated
|
|
wireless user data (Data) or protocol control (Management) frames
|
|
causes the resulting CAPWAP protocol packet to exceed the MTU
|
|
supported between the WTP and AC. Fragmented CAPWAP packets are
|
|
reassembled to reconstitute the original encapsulated payload.
|
|
|
|
The CAPWAP protocol provides for the delivery of commands from the AC
|
|
to the WTP for the management of stations that are communicating with
|
|
the WTP. This may include the creation of local data structures in
|
|
the WTP for the stations and the collection of statistical
|
|
information about the communication between the WTP and the stations.
|
|
The CAPWAP protocol provides a mechanism for the AC to obtain
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 8]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
statistical information collected by the WTP.
|
|
|
|
The CAPWAP protocol provides for a keep alive feature that preserves
|
|
the communication channel between the WTP and AC. If the AC fails to
|
|
appear alive, the WTP will try to discover a new AC.
|
|
|
|
<span class="h3"><a class="selflink" name="section-2.1" href="#section-2.1">2.1</a>. Wireless Binding Definition</span>
|
|
|
|
The CAPWAP protocol is independent of a specific WTP radio
|
|
technology. Elements of the CAPWAP protocol are designed to
|
|
accommodate the specific needs of each wireless technology in a
|
|
standard way. Implementation of the CAPWAP protocol for a particular
|
|
wireless technology MUST follow the binding requirements defined for
|
|
that technology.
|
|
|
|
When defining a binding for wireless technologies, the authors MUST
|
|
include any necessary definitions for technology-specific messages
|
|
and all technology-specific message elements for those messages. At
|
|
a minimum, a binding MUST provide:
|
|
|
|
1 - The definition for a binding-specific Statistics message
|
|
element, carried in the WTP Event Request message
|
|
|
|
2 - A message element carried in the Station Configuration Request
|
|
message to configure station information on the WTP
|
|
|
|
3 - A WTP Radio Information message element carried in the
|
|
Discovery, Primary Discovery and Join Request and Response
|
|
messages, indicating the binding specific radio types supported at
|
|
the WTP and AC.
|
|
|
|
If technology specific message elements are required for any of the
|
|
existing CAPWAP messages defined in this specification, they MUST
|
|
also be defined in the technology binding document.
|
|
|
|
The naming of binding-specific message elements MUST begin with the
|
|
name of the technology type, e.g., the binding for IEEE 802.11,
|
|
provided in [<a href="#ref-12" title=""CAPWAP Protocol Binding for IEEE 802.11"">12</a>], begins with "IEEE 802.11".
|
|
|
|
The CAPWAP binding concept is also used in any future specifications
|
|
that add functionality to either the base CAPWAP protocol
|
|
specification, or any published CAPWAP binding specification. A
|
|
separate WTP Radio Information message element MUST be created to
|
|
properly advertise support for the specification. This mechanism
|
|
allows for future protocol extensibility, while providing the
|
|
necessary capabilities advertisement, through the WTP Radio
|
|
Information message element, to ensure WTP/AC interoperability.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 9]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-2.2" href="#section-2.2">2.2</a>. CAPWAP Session Establishment Overview</span>
|
|
|
|
This section describes the session establishment process message
|
|
exchanges in the ideal case. The annotated ladder diagram shows the
|
|
AC on the right, the WTP on the left, and assumes the use of
|
|
certificates for DTLS authentication. The CAPWAP Protocol State
|
|
Machine is described in detail in <a href="#section-2.3">Section 2.3</a>. Note that DTLS allows
|
|
certain messages to be aggregated into a single frame, which is
|
|
denoted via an asterix in the following figure.
|
|
|
|
============ ============
|
|
WTP AC
|
|
============ ============
|
|
[----------- begin optional discovery ------------]
|
|
|
|
Discover Request
|
|
------------------------------------>
|
|
Discover Response
|
|
<------------------------------------
|
|
|
|
[----------- end optional discovery ------------]
|
|
|
|
(-- begin DTLS handshake --)
|
|
|
|
ClientHello
|
|
------------------------------------>
|
|
HelloVerifyRequest (with cookie)
|
|
<------------------------------------
|
|
|
|
|
|
ClientHello (with cookie)
|
|
------------------------------------>
|
|
ServerHello,
|
|
Certificate,
|
|
ServerHelloDone*
|
|
<------------------------------------
|
|
|
|
(-- WTP callout for AC authorization --)
|
|
|
|
Certificate (optional),
|
|
ClientKeyExchange,
|
|
CertificateVerify (optional),
|
|
ChangeCipherSpec,
|
|
Finished*
|
|
------------------------------------>
|
|
|
|
(-- AC callout for WTP authorization --)
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 10]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
ChangeCipherSpec,
|
|
Finished*
|
|
<------------------------------------
|
|
|
|
(-- DTLS session is established now --)
|
|
|
|
Join Request
|
|
------------------------------------>
|
|
Join Response
|
|
<------------------------------------
|
|
|
|
(-- assume image is up to date --)
|
|
|
|
Configuration Status Request
|
|
------------------------------------>
|
|
Configuration Status Response
|
|
<------------------------------------
|
|
|
|
(-- enter RUN state --)
|
|
|
|
:
|
|
:
|
|
|
|
Echo Request
|
|
------------------------------------>
|
|
Echo Response
|
|
<------------------------------------
|
|
|
|
:
|
|
:
|
|
|
|
Event Request
|
|
------------------------------------>
|
|
Event Response
|
|
<------------------------------------
|
|
|
|
:
|
|
:
|
|
|
|
At the end of the illustrated CAPWAP message exchange, the AC and WTP
|
|
are securely exchanging CAPWAP control messages. This is an
|
|
idealized illustration, provided to clarify protocol operation.
|
|
<a href="#section-2.3">Section 2.3</a> provides a detailed description of the corresponding
|
|
state machine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 11]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-2.3" href="#section-2.3">2.3</a>. CAPWAP State Machine Definition</span>
|
|
|
|
The following state diagram represents the lifecycle of a WTP-AC
|
|
session. Use of DTLS by the CAPWAP protocol results in the
|
|
juxtaposition of two nominally separate yet tightly bound state
|
|
machines. The DTLS and CAPWAP state machines are coupled through an
|
|
API consisting of commands (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>) and notifications
|
|
(see <a href="#section-2.3.2.2">Section 2.3.2.2</a>). Certain transitions in the DTLS state machine
|
|
are triggered by commands from the CAPWAP state machine, while
|
|
certain transitions in the CAPWAP state machine are triggered by
|
|
notifications from the DTLS state machine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 12]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
/-------------------------\
|
|
w| |
|
|
5+----------+ x +------------+ |
|
|
| Run |-->| Reset |-\|
|
|
+----------+ +------------+ ||
|
|
u ^ ^ ^ y||
|
|
+------------+--------/ | | ||
|
|
| Data Check | /-------/ | ||
|
|
+------------+<-------\ | | ||
|
|
| | ||
|
|
/------------------+--------\ | ||
|
|
r| t| s| 4 v o| ||
|
|
+--------+ +-----------+ +--------------+||
|
|
| Join |---->| Configure | | Image Data |||
|
|
+--------+ q +-----------+ +--------------+||
|
|
^ p| V| x| ||
|
|
| | \-------------------\ | ||
|
|
| \--------------------------------------\| | ||
|
|
\------------------------\ || | ||
|
|
/--------------<----------------+--------------\ || | ||
|
|
| /------------<-------------\ | | || | ||
|
|
| | m| |n z| vv v vv
|
|
| | +----------------+ +--------------+ +-----------+
|
|
| | | DTLS Setup | | DTLS Connect | | DTLS TD |
|
|
| | +----------------+ +--------------+ +-----------+
|
|
| | g| ^ ^ |h ^ ^
|
|
v v | | | | | |
|
|
| | | | | \-------\ | /-----------/
|
|
| | | | | | | |
|
|
| | v |e f| 2 v |j |k
|
|
| \->+------+ +------+ +-----------+
|
|
| | Idle |-->| Disc | | Authorize |
|
|
\--->+------+ a +------+ +-----------+
|
|
b| ^ |c
|
|
| | /----/
|
|
v d| |
|
|
+---------+ |
|
|
| Sulking |<-/
|
|
3 +---------+
|
|
|
|
Figure 3: CAPWAP Integrated State Machine
|
|
|
|
The CAPWAP protocol state machine, depicted above, is used by both
|
|
the AC and the WTP. In cases where states are not shared (i.e. not
|
|
implemented in one or the other of the AC or WTP), this is explicitly
|
|
called out in the transition descriptions below. For every state
|
|
defined, only certain messages are permitted to be sent and received.
|
|
The CAPWAP control messages definitions specify the state(s) in which
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 13]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
each message is valid.
|
|
|
|
Since the WTP only communicates with a single AC, it only has a
|
|
single instance of the CAPWAP state machine. The AC has a separate
|
|
instance of the CAPWAP state machine per WTP it is communicating
|
|
with.
|
|
|
|
<span class="h4"><a class="selflink" name="section-2.3.1" href="#section-2.3.1">2.3.1</a>. CAPWAP Protocol State Transitions</span>
|
|
|
|
This section describes the various state transitions, and the events
|
|
that cause them. This section does not discuss interactions between
|
|
DTLS- and CAPWAP-specific states. Those interactions, and DTLS-
|
|
specific states and transitions, are discussed in <a href="#section-2.3.2">Section 2.3.2</a>.
|
|
|
|
Idle to Discovery (a): This transition occurs once device
|
|
initialization is complete.
|
|
|
|
WTP: The WTP enters the Discovery state prior to transmitting the
|
|
first Discovery Request message (see <a href="#section-5.1">Section 5.1</a>). Upon
|
|
entering this state, the WTP sets the DiscoveryInterval timer
|
|
(see <a href="#section-4.7">Section 4.7</a>). The WTP resets the DiscoveryCount counter
|
|
to zero (0) (see <a href="#section-4.8">Section 4.8</a>). The WTP also clears all
|
|
information from ACs it may have received during a previous
|
|
Discovery phase.
|
|
|
|
AC: The AC does not maintain state information for the WTP upon
|
|
reception of the Discovery Request message, but it SHOULD
|
|
respond with a Discovery Response message (see <a href="#section-5.2">Section 5.2</a>).
|
|
This transition is a no-op for the AC.
|
|
|
|
Idle to Sulking (b): This transition occurs to force the WTP and AC
|
|
to enter a quiet period to avoid repeatedly attempting to
|
|
establish a connection.
|
|
|
|
WTP: The WTP enters this state when the FailedDTLSSessionCount or
|
|
the FailedDTLSAuthFailCount counter reaches
|
|
MaxFailedDTLSSessionRetry variable (see <a href="#section-4.8">Section 4.8</a>). Upon
|
|
entering this state, the WTP MUST start the SilentInterval
|
|
timer. While in the Sulking state, all received CAPWAP and
|
|
DTLS protocol messages received MUST be ignored.
|
|
|
|
AC: The AC enters this state with the specific WTP when the
|
|
FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter
|
|
reaches MaxFailedDTLSSessionRetry variable (see <a href="#section-4.8">Section 4.8</a>).
|
|
Upon entering this state, the AC MUST start the SilentInterval
|
|
timer. While in the Sulking state, all received CAPWAP and
|
|
DTLS protocol messages received from the WTP MUST be ignored.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 14]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Discovery to Discovery (2): In the Discovery state, the WTP
|
|
determines which AC to connect to.
|
|
|
|
WTP: This transition occurs when the DiscoveryInterval timer
|
|
expires. If the WTP is configured with a list of ACs, it
|
|
transmits a Discovery Request message to every AC from which it
|
|
has not received a Discovery Response message. For every
|
|
transition to this event, the WTP increments the DiscoveryCount
|
|
counter. See <a href="#section-5.1">Section 5.1</a> for more information on how the WTP
|
|
knows the ACs to which it should transmit the Discovery Request
|
|
messages. The WTP restarts the DiscoveryInterval timer
|
|
whenever it transmits Discovery Request messages.
|
|
|
|
AC: This is a no-op.
|
|
|
|
Discovery to Sulking (c): This transition occurs on a WTP when
|
|
Discovery or connectivity to the AC fails.
|
|
|
|
WTP: The WTP enters this state when the DiscoveryInterval timer
|
|
expires or the DiscoveryCount variable is equal to the
|
|
MaxDiscoveries variable (see <a href="#section-4.8">Section 4.8</a>). Upon entering this
|
|
state, the WTP MUST start the SilentInterval timer. While in
|
|
the Sulking state, all received CAPWAP protocol messages
|
|
received MUST be ignored.
|
|
|
|
AC: This is a no-op.
|
|
|
|
Sulking to Idle (d): This transition occurs on a WTP when it must
|
|
restart the discovery phase.
|
|
|
|
WTP: The WTP enters this state when the SilentInterval timer (see
|
|
<a href="#section-4.7">Section 4.7</a>) expires. The FailedDTLSSessionCount,
|
|
DiscoveryCount and FailedDTLSAuthFailCount counters are reset
|
|
to zero.
|
|
|
|
AC: The AC enters this state when the SilentInterval timer (see
|
|
<a href="#section-4.7">Section 4.7</a>) expires. The FailedDTLSSessionCount,
|
|
DiscoveryCount and FailedDTLSAuthFailCount counters are reset
|
|
to zero.
|
|
|
|
Sulking to Sulking (3): The Sulking state provides the silent
|
|
period, minimizing the possibility for Denial of Service (DoS)
|
|
attacks.
|
|
|
|
WTP: All packets received from the AC while in the sulking state
|
|
are ignored.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 15]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
AC: All packets receive from the WTP while in the sulking state
|
|
are ignored.
|
|
|
|
Idle to DTLS Setup (e): This transition occurs to establish a secure
|
|
DTLS session with the peer.
|
|
|
|
WTP: The WTP initiates this transition by invoking the DTLSStart
|
|
command, which starts the DTLS session establishment with the
|
|
chosen AC. When the discovery phase is bypassed, it is assumed
|
|
the WTP has a locally configured AC.
|
|
|
|
AC: The AC initiates this transition by invoking the DTLSListen
|
|
command, which informs the DTLS stack that it is willing to
|
|
listen for an incoming session. The AC MAY provide optional
|
|
qualifiers in the DTLSListen command to only accept session
|
|
requests from specific WTPs.
|
|
|
|
Discovery to DTLS Setup (f): This transition occurs to establish a
|
|
secure DTLS session with the peer.
|
|
|
|
WTP: The WTP initiates this transition by invoking the DTLSStart
|
|
command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>), which starts the DTLS session
|
|
establishment with the chosen AC. The decision of which AC to
|
|
connect to is the result of the discovery phase, which is
|
|
described in <a href="#section-3.3">Section 3.3</a>.
|
|
|
|
AC: The AC initiates this transition by invoking the DTLSListen
|
|
command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>), which informs the DTLS stack
|
|
that it is willing to listen for an incoming session. The AC
|
|
MAY have maintained state information when it received the
|
|
Discovery Request message to provide optional qualifiers in the
|
|
DTLSListen command to only accept session requests from a
|
|
specific WTP. Note that maintaining state information based on
|
|
an unsecured Discovery Request message MAY lead to a Denial of
|
|
Service attack. Therefore the AC SHOULD ensure that the state
|
|
information is freed after a period, which is implementation
|
|
specific.
|
|
|
|
DTLS Setup to Idle (g): This transition occurs when the DTLS Session
|
|
failed to be established.
|
|
|
|
WTP: The WTP initiates this state transition when it receives a
|
|
DTLSEstablishFail notification from DTLS (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>).
|
|
This error notification aborts the secure DTLS session
|
|
establishment. When this notification is received, the
|
|
FailedDTLSSessionCount counter is incremented.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 16]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
AC: The WTP initiates this state transition when it receives a
|
|
DTLSEstablishFail notification from DTLS (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>).
|
|
This error notification aborts the secure DTLS session
|
|
establishment. When this notification is received, the
|
|
FailedDTLSSessionCount counter is incremented.
|
|
|
|
DTLS Setup to Authorize (h): This transition occurs when an incoming
|
|
DTLS session is being established, and the DTLS stack needs
|
|
authorization to proceed with the session establishment.
|
|
|
|
WTP: This state transition occurs when the WTP receives the
|
|
DTLSPeerAuthorize notification (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>). Upon
|
|
entering this state, the WTP performs an authorization check
|
|
against the AC credentials. See <a href="#section-2.4.4">Section 2.4.4</a> for more
|
|
information on AC authorization.
|
|
|
|
AC: This state transition occurs when the AC receives the
|
|
DTLSPeerAuthorize notification (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>). Upon
|
|
entering this state, the AC performs an authorization check
|
|
against the WTP credentials. See <a href="#section-2.4.4">Section 2.4.4</a> for more
|
|
information on WTP authorization.
|
|
|
|
Authorize to DTLS Connect (j): This transition occurs to notify the
|
|
DTLS stack that the session should be established.
|
|
|
|
WTP: This state transition occurs when the WTP has either opted
|
|
to forgo the authorization check of the AC's credentials, or
|
|
the credentials were successfully authorized. This is done by
|
|
invoking the DTLSAccept DTLS command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
|
|
AC: This state transition occurs when the AC has either opted to
|
|
forgo the authorization check of the WTP's credentials, or the
|
|
credentials were successfully authorized. This is done by
|
|
invoking the DTLSAccept DTLS command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
|
|
Authorize to DTLS Teardown (k): This transition occurs to notify the
|
|
DTLS stack that the session should be aborted.
|
|
|
|
WTP: This state transition occurs when the WTP was unable to
|
|
authorize the AC, using the AC credentials. The WTP then
|
|
aborts the DTLS session by invoking the DTLSAbortSession
|
|
command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
|
|
AC: This state transition occurs when the AC was unable to
|
|
authorize the WTP, using the WTP credentials. The AC then
|
|
aborts the DTLS session by invoking the DTLSAbortSession
|
|
command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 17]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
DTLS Connect to Idle (m): This transition occurs when the DTLS
|
|
Session failed to be established.
|
|
|
|
WTP: This state transition occurs when the WTP receives either a
|
|
DTLSAborted or DTLSAuthenticateFail notification (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>), indicating that the DTLS session was not
|
|
successfully established. When this transition occurs due to
|
|
the DTLSAuthenticateFail notification, the
|
|
FailedDTLSAuthFailCount is incremented, otherwise the
|
|
FailedDTLSSessionCount counter is incremented.
|
|
|
|
AC: This state transition occurs when the AC receives either a
|
|
DTLSAborted or DTLSAuthenticateFail notification (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>), indicating that the DTLS session was not
|
|
successfully established. When this transition occurs due to
|
|
the DTLSAuthenticateFail notification, the
|
|
FailedDTLSAuthFailCount is incremented, otherwise the
|
|
FailedDTLSSessionCount counter is incremented.
|
|
|
|
DTLS Connect to Join (n): This transition occurs when the DTLS
|
|
Session is successfully established.
|
|
|
|
WTP: This state transition occurs when the WTP receives the
|
|
DTLSEstablished notification (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>), indicating
|
|
that the DTLS session was successfully established. When this
|
|
notification is received, the FailedDTLSSessionCount counter is
|
|
set to zero.
|
|
|
|
AC: This state transition occurs when the AC receives the
|
|
DTLSEstablished notification (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>), indicating
|
|
that the DTLS session was successfully established. When this
|
|
notification is received, the FailedDTLSSessionCount counter is
|
|
set to zero, and the WaitJoin timer is started (see
|
|
<a href="#section-4.7">Section 4.7</a>).
|
|
|
|
Join to DTLS Teardown (p): This transition occurs when the join
|
|
process failed.
|
|
|
|
WTP: This state transition occurs when the WTP receives a Join
|
|
Response message with a Result Code message element containing
|
|
an error, if the Image Identifier provided by the AC in the
|
|
Join Response message differs from the WTP's currently running
|
|
firmware version and the WTP has the requested image in its
|
|
non-volatile memory, or if the WaitDTLS timer expires. This
|
|
causes the WTP to initiate the DTLSShutdown command (see
|
|
<a href="#section-2.3.2.1">Section 2.3.2.1</a>). This transition also occurs if the WTP
|
|
receives one of the following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 18]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
AC: This state transition occurs either if the WaitJoin timer
|
|
expires or if the AC transmits a Join Response message with a
|
|
Result Code message element containing an error. This causes
|
|
the AC to initiate the DTLSShutdown command (see
|
|
<a href="#section-2.3.2.1">Section 2.3.2.1</a>). This transition also occurs if the AC
|
|
receives one of the following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect.
|
|
|
|
Join to Image Data (r): This state transition is used by the WTP and
|
|
the AC to download executable firmware.
|
|
|
|
WTP: The WTP enters the Image Data state when it receives a
|
|
successful Join Response message and determines and the
|
|
included Image Identifier message element is not the same as
|
|
its currently running image. The WTP also detects that the
|
|
requested image version is not currently available in the WTP's
|
|
non-volatile storage (see <a href="#section-9.1">Section 9.1</a> for a full description of
|
|
the firmware download process). The WTP initializes the
|
|
EchoInterval timer (see <a href="#section-4.7">Section 4.7</a>), and transmits the Image
|
|
Data Request message (see <a href="#section-9.1.1">Section 9.1.1</a>) requesting the start
|
|
of the firmware download.
|
|
|
|
AC: This state transition occurs when the AC receives the Image
|
|
Data Request message from the WTP. The AC MUST transmit an
|
|
Image Data Response message (see <a href="#section-9.1.2">Section 9.1.2</a>) to the WTP,
|
|
which includes a portion of the firmware. The AC MUST start
|
|
the NeighborDeadInterval timer (see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
Join to Configure (q): This state transition is used by the WTP and
|
|
the AC to exchange configuration information.
|
|
|
|
WTP: The WTP enters the Configure state when it receives a
|
|
successful Join Response, and determines that the included
|
|
Image Identifier message element is the same as its currently
|
|
running image. The WTP transmits the Configuration Status
|
|
message (see <a href="#section-8.2">Section 8.2</a>) to the AC with message elements
|
|
describing its current configuration. The WTP also starts the
|
|
ResponseTimeout timer (see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
AC: This state transition occurs immediately after the AC
|
|
transmits the Join Response message to the WTP. If the AC
|
|
receives the Configuration Status message from the WTP, the AC
|
|
MUST transmit a Configuration Status Response message (see
|
|
<a href="#section-8.3">Section 8.3</a>) to the WTP, and MAY include specific message
|
|
elements to override the WTP's configuration. The WTP also
|
|
starts the ChangeStatePendingTimer timer (see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 19]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Configure to Reset (s): This state transition is used to reset the
|
|
connection either due to an error during the configuration phase,
|
|
or when the WTP determines it needs to reset in order for the new
|
|
configuration to take effect.
|
|
|
|
WTP: The WTP enters the Reset state when it receives a
|
|
Configuration Status Response indicating an error or when it
|
|
determines that a reset of the WTP is required, due to the
|
|
characteristics of a new configuration.
|
|
|
|
AC: The AC transitions to the Reset state when it receives a
|
|
Change State Event message from the WTP that contains an error
|
|
for which AC policy does not permit the WTP to provide service.
|
|
This state transition also occurs when the AC
|
|
ChangeStatePendingTimer timer expires.
|
|
|
|
Configure to DTLS Teardown (V): This transition occurs when the
|
|
configuration process aborts due to a DTLS error.
|
|
|
|
WTP: The WTP enters this state when it receives one of the
|
|
following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>). The WTP MAY tear down the DTLS session if it
|
|
receives frequent DTLSDecapFailure notifications.
|
|
|
|
AC: The AC enters this state when it receives one of the
|
|
following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>). The WTP MAY tear down the DTLS session if it
|
|
receives frequent DTLSDecapFailure notifications.
|
|
|
|
Image Data to Image Data (4): The Image Data state is used by the
|
|
WTP and the AC during the firmware download phase.
|
|
|
|
WTP: The WTP enters the Image Data state when it receives an
|
|
Image Data Response message indicating that the AC has more
|
|
data to send.
|
|
|
|
AC: This state transition occurs when the AC receives the Image
|
|
Data Request message from the WTP while already in the Image
|
|
Data state, and it detects that the firmware download has not
|
|
completed.
|
|
|
|
Image Data to Reset (o): This state transition is used to reset the
|
|
DTLS connection prior to restarting the WTP after an image
|
|
download.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 20]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
WTP: When an image download completes, the WTP enters the Reset
|
|
state. The WTP MAY also transition to this state upon
|
|
receiving an Image Data Response message from the AC (see
|
|
<a href="#section-9.1.2">Section 9.1.2</a>) indicating a failure.
|
|
|
|
AC: The AC enters the Reset state when the image download is
|
|
complete, or if an error occurs during the image download
|
|
process.
|
|
|
|
Image Data to DTLS Teardown (x): This transition occurs when the
|
|
firmware download process aborts due to a DTLS error.
|
|
|
|
WTP: The WTP enters this state when it receives one of the
|
|
following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>). The WTP MAY tear down the DTLS session if it
|
|
receives frequent DTLSDecapFailure notifications.
|
|
|
|
AC: The AC enters this state when it receives one of the
|
|
following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>). The WTP MAY tear down the DTLS session if it
|
|
receives frequent DTLSDecapFailure notifications.
|
|
|
|
Configure to Data Check (t): This state transition occurs when the
|
|
WTP and AC confirm the configuration.
|
|
|
|
WTP: The WTP enters this state when it receives a successful
|
|
Configuration Status Response message from the AC. The WTP
|
|
initializes the EchoInterval timer (see <a href="#section-4.7">Section 4.7</a>), and
|
|
transmits the Change State Event Request message (see
|
|
<a href="#section-8.6">Section 8.6</a>).
|
|
|
|
AC: This state transition occurs when the AC receives the Change
|
|
State Event Request message (see <a href="#section-8.6">Section 8.6</a>) from the WTP.
|
|
The AC responds with a Change State Event Response message (see
|
|
<a href="#section-8.7">Section 8.7</a>). The AC MUST start the NeighborDeadInterval timer
|
|
(see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
Data Check to Run (u): This state transition occurs when the linkage
|
|
between the control and data channels has occured, causing the WTP
|
|
and AC to enter their normal state of operation.
|
|
|
|
WTP: The WTP enters this state when it receives a successful
|
|
Change State Event Response message from the AC. The WTP
|
|
initiates the data channel, which MAY require the establishment
|
|
of a DTLS session, starts the DataChannelKeepAlive timer (see
|
|
<a href="#section-4.7">Section 4.7</a>) and transmits a Data Channel Keep Alive packet
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 21]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
(see <a href="#section-4.4.1">Section 4.4.1</a>). The WTP then starts the
|
|
DataChannelDeadInterval timer (see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
AC: This state transition occurs when the AC receives the Data
|
|
Channel Keep Alive packet (see <a href="#section-4.4.1">Section 4.4.1</a>), with a Session
|
|
ID message element matching that included by the WTP in the
|
|
Join Request message. Note that if AC policy is to require the
|
|
data channel to be encrypted, this process would also require
|
|
the establishment of a data channel DTLS session. Upon
|
|
receiving the Data Channel Keep Alive packet, the AC transmits
|
|
its own Data Channel Keep Alive packet.
|
|
|
|
Run to DTLS Teardown (u): This state transition occurs when an error
|
|
has occured in the DTLS stack, causing the DTLS session to be
|
|
torndown.
|
|
|
|
WTP: The WTP enters this state when it receives one of the
|
|
following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>). The WTP MAY tear down the DTLS session if it
|
|
receives frequent DTLSDecapFailure notifications. The WTP also
|
|
transitions to this state if the underlying reliable
|
|
transport's RetransmitCount counter has reached the
|
|
MaxRetransmit variable (see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
AC: The AC enters this state when it receives one of the
|
|
following DTLS notifications: DTLSAborted,
|
|
DTLSReassemblyFailure or DTLSPeerDisconnect (see
|
|
<a href="#section-2.3.2.2">Section 2.3.2.2</a>). The WTP MAY tear down the DTLS session if it
|
|
receives frequent DTLSDecapFailure notifications. The AC
|
|
transitions to this state if the underlying reliable
|
|
transport's RetransmitCount counter has reached the
|
|
MaxRetransmit variable (see <a href="#section-4.7">Section 4.7</a>).
|
|
|
|
Run to Run (5): This is the normal state of operation.
|
|
|
|
WTP: This is the WTP's normal state of operation. There are many
|
|
events that result this state transition:
|
|
|
|
Configuration Update: The WTP receives a Configuration Update
|
|
Request message(see <a href="#section-8.4">Section 8.4</a>). The WTP MUST respond with
|
|
a Configuration Update Response message (see <a href="#section-8.5">Section 8.5</a>).
|
|
|
|
Change State Event: The WTP receives a Change State Event
|
|
Response message, or determines that it must initiate a
|
|
Change State Event Request message, as a result of a failure
|
|
or change in the state of a radio.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 22]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Echo Request: The WTP sends an Echo Request message
|
|
(<a href="#section-7.1">Section 7.1</a>) or receives the corresponding Echo Response
|
|
message, (see <a href="#section-7.2">Section 7.2</a>) from the AC.
|
|
|
|
Clear Config Request: The WTP receives a Clear Configuration
|
|
Request message (see <a href="#section-8.8">Section 8.8</a>). The WTP MUST reset its
|
|
configuration back to manufacturer defaults.
|
|
|
|
WTP Event: The WTP sends a WTP Event Request message,
|
|
delivering information to the AC (see <a href="#section-9.4">Section 9.4</a>). The WTP
|
|
receives a WTP Event Response message from the AC (see
|
|
<a href="#section-9.5">Section 9.5</a>).
|
|
|
|
Data Transfer: The WTP sends a Data Transfer Request message
|
|
to the AC (see <a href="#section-9.6">Section 9.6</a>). The WTP receives a Data
|
|
Transfer Response message from the AC (see <a href="#section-9.7">Section 9.7</a>).
|
|
|
|
Station Configuration Request: The WTP receives a Station
|
|
Configuration Request message (see <a href="#section-10.1">Section 10.1</a>), to which
|
|
it MUST respond with a Station Configuration Response
|
|
message (see <a href="#section-10.2">Section 10.2</a>).
|
|
|
|
AC: This is the AC's normal state of operation:
|
|
|
|
Configuration Update: The AC sends a Configuration Update
|
|
Request message (see <a href="#section-8.4">Section 8.4</a>) to the WTP to update its
|
|
configuration. The AC receives a Configuration Update
|
|
Response message (see <a href="#section-8.5">Section 8.5</a>) from the WTP.
|
|
|
|
Change State Event: The AC receives a Change State Event
|
|
Request message (see <a href="#section-8.6">Section 8.6</a>), to which it MUST respond
|
|
with the Change State Event Response message (see
|
|
<a href="#section-8.7">Section 8.7</a>).
|
|
|
|
Echo Request: The AC receives an Echo Request message (see
|
|
<a href="#section-7.1">Section 7.1</a>), to which it MUST respond with an Echo Response
|
|
message(see <a href="#section-7.2">Section 7.2</a>).
|
|
|
|
Clear Config Response: The AC receives a Clear Configuration
|
|
Response message from the WTP (see <a href="#section-8.9">Section 8.9</a>).
|
|
|
|
WTP Event: The AC receives a WTP Event Request message from
|
|
the WTP (see <a href="#section-9.4">Section 9.4</a>) and MUST generate a corresponding
|
|
WTP Event Response message (see <a href="#section-9.5">Section 9.5</a>).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 23]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Data Transfer: The AC receives a Data Transfer Request message
|
|
from the WTP (see <a href="#section-9.6">Section 9.6</a>) and MUST generate a
|
|
corresponding Data Transfer Response message (see
|
|
<a href="#section-9.7">Section 9.7</a>).
|
|
|
|
Station Configuration Request: The AC sends a Station
|
|
Configuration Request message (see <a href="#section-10.1">Section 10.1</a>) or receives
|
|
the corresponding Station Configuration Response message
|
|
(see <a href="#section-10.2">Section 10.2</a>) from the WTP.
|
|
|
|
Run to Reset (x): This state transition is used when either the AC
|
|
or WTP tear down the connection. This may occur as part of normal
|
|
operation, or due to error conditions.
|
|
|
|
WTP: The WTP enters the Reset state when it receives a Reset
|
|
Request message from the AC.
|
|
|
|
AC: The AC enters the Reset state when it transmits a Reset
|
|
Request message to the WTP.
|
|
|
|
Reset to DTLS Teardown (y): This transition occurs when the CAPWAP
|
|
reset is complete, to terminate the DTLS session.
|
|
|
|
WTP: This state transition occurs when the WTP receives a Reset
|
|
Response message. This causes the WTP to initiate the
|
|
DTLSShutdown command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
|
|
AC: This state transition occurs when the AC transmits a Reset
|
|
Response message. The AC does not invoke the DTLSShutdown
|
|
command (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
|
|
DTLS Teardown to Idle (z): This transition occurs when the DTLS
|
|
session has been shutdown.
|
|
|
|
WTP: This state transition occurs when the WTP has successfully
|
|
cleaned up all resources associated with the control plane DTLS
|
|
session. The data plane DTLS session is also shutdown, and all
|
|
resources freed, if a DTLS session was established for the data
|
|
plane. Any timers set for the current instance of the state
|
|
machine are also cleared.
|
|
|
|
AC: This state transition occurs when the AC has successfully
|
|
cleaned up all resources associated with the control plane DTLS
|
|
session. The data plane DTLS session is also shutdown, and all
|
|
resources freed, if a DTLS session was established for the data
|
|
plane. Any timers set for the current instance of the state
|
|
machine are also cleared.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 24]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-25" id="page-25" href="#page-25" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-2.3.2" href="#section-2.3.2">2.3.2</a>. CAPWAP/DTLS Interface</span>
|
|
|
|
This section describes the DTLS Commands used by CAPWAP, and the
|
|
notifications received from DTLS to the CAPWAP protocol stack.
|
|
|
|
<span class="h5"><a class="selflink" name="section-2.3.2.1" href="#section-2.3.2.1">2.3.2.1</a>. CAPWAP to DTLS Commands</span>
|
|
|
|
Six commands are defined for the CAPWAP to DTLS API. These
|
|
"commands" are conceptual, and may be implemented as one or more
|
|
function calls. This API definition is provided to clarify
|
|
interactions between the DTLS and CAPWAP components of the integrated
|
|
CAPWAP state machine.
|
|
|
|
Below is a list of the minimal command API:
|
|
|
|
o DTLSStart is sent to the DTLS component to cause a DTLS session to
|
|
be established. Upon invoking the DTLSStart command, the WaitDTLS
|
|
timer is started. The WTP initiates this DTLS command, as the AC
|
|
does not initiate DTLS sessions.
|
|
|
|
o DTLSListen is sent to the DTLS component to allow the DTLS
|
|
component to listen for incoming DTLS session requests.
|
|
|
|
o DTLSAccept is sent to the DTLS component to allow the DTLS session
|
|
establishment to continue successfully.
|
|
|
|
o DTLSAbortSession is sent to the DTLS component to cause the
|
|
session that is in the process of being established to be aborted.
|
|
This command is also sent when the WaitDTLS timer expires. When
|
|
this command is executed, the FailedDTLSSessionCount counter is
|
|
incremented.
|
|
|
|
o DTLSShutdown is sent to the DTLS component to cause session
|
|
teardown.
|
|
|
|
o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU
|
|
size used by the DTLS component. The default size is 1468 bytes.
|
|
|
|
<span class="h5"><a class="selflink" name="section-2.3.2.2" href="#section-2.3.2.2">2.3.2.2</a>. DTLS to CAPWAP Notifications</span>
|
|
|
|
DTLS notifications are defined for the DTLS to CAPWAP API. These
|
|
"notifications" are conceptual, and may be implemented in numerous
|
|
ways (e.g. as function return values). This API definition is
|
|
provided to clarify interactions between the DTLS and CAPWAP
|
|
components of the integrated CAPWAP state machine. It is important
|
|
to note that the notifications listed below MAY cause the CAPWAP
|
|
state machine to jump from one state to another using a state
|
|
transition not listed in <a href="#section-2.3.1">Section 2.3.1</a>. When a notification listed
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 25]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-26" id="page-26" href="#page-26" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
below occurs, the target CAPWAP state shown in Figure 3 becomes the
|
|
current state.
|
|
|
|
Below is a list of the API notifications:
|
|
|
|
o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS
|
|
session establishment once the peer's identity has been received.
|
|
This notification MAY be used by the CAPWAP component to authorize
|
|
the session, based on the peer's identity. The authorization
|
|
process will lead to the CAPWAP component initiating either the
|
|
DTLSAccept or DTLSAbortSession commands.
|
|
|
|
o DTLSEstablished is sent to the CAPWAP component to indicate that
|
|
that a secure channel now exists, using the parameters provided
|
|
during the DTLS initialization process. When this notification is
|
|
received, the FailedDTLSSessionCount counter is reset to zero.
|
|
When this notification is received, the WaitDTLS timer is stopped.
|
|
|
|
o DTLSEstablishFail is sent when the DTLS session establishment has
|
|
failed, either due to a local error, or due to the peer rejecting
|
|
the session establishment. When this notification is received,
|
|
the FailedDTLSSessionCount counter is incremented.
|
|
|
|
o DTLSAuthenticateFail is sent when DTLS session establishment
|
|
failed due to an authentication error. When this notification is
|
|
received, the FailedDTLSAuthFailCount counter is incremented.
|
|
|
|
o DTLSAborted is sent to the CAPWAP component to indicate that
|
|
session abort (as requested by CAPWAP) is complete; this occurs to
|
|
confirm a DTLS session abort, or when the WaitDTLS timer expires.
|
|
When this notification is received, the WaitDTLS timer is stopped.
|
|
|
|
o DTLSReassemblyFailure MAY be sent to the CAPWAP component to
|
|
indicate DTLS fragment reassembly failure.
|
|
|
|
o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a
|
|
decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP
|
|
module to indicate an encryption/authentication failure. This
|
|
notification is intended for informative purposes only, and is not
|
|
intended to cause a change in the CAPWAP state machine (see
|
|
<a href="#section-12.4">Section 12.4</a>).
|
|
|
|
o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the
|
|
DTLS session has been torn down. Note that this notification is
|
|
only received if the DTLS session has been established.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 26]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-27" id="page-27" href="#page-27" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-2.4" href="#section-2.4">2.4</a>. Use of DTLS in the CAPWAP Protocol</span>
|
|
|
|
DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP
|
|
protocol. In this document DTLS and CAPWAP are discussed as
|
|
nominally distinct entitites; however they are very closely coupled,
|
|
and may even be implemented inseparably. Since there are DTLS
|
|
library implementations currently available, and since security
|
|
protocols (e.g. IPsec, TLS) are often implemented in widely
|
|
available acceleration hardware, it is both convenient and forward-
|
|
looking to maintain a modular distinction in this document.
|
|
|
|
This section describes a detailed walk-through of the interactions
|
|
between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
|
|
to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
|
|
encountered during the normal course of operation.
|
|
|
|
<span class="h4"><a class="selflink" name="section-2.4.1" href="#section-2.4.1">2.4.1</a>. DTLS Handshake Processing</span>
|
|
|
|
Details of the DTLS handshake process are specified in [<a href="#ref-8" title=""Datagram Transport Layer Security"">8</a>]. This
|
|
section describes the interactions between the DTLS session
|
|
establishment process and the CAPWAP protocol. Note that the
|
|
conceptual DTLS state is shown below to help understand the point at
|
|
which the DTLS states transition. In the normal case, the DTLS
|
|
handshake will proceed as follows (NOTE: this example uses
|
|
certificates, but preshared keys are also supported):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 27]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-28" id="page-28" href="#page-28" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
============ ============
|
|
WTP AC
|
|
============ ============
|
|
ClientHello ------>
|
|
<------ HelloVerifyRequest
|
|
(with cookie)
|
|
|
|
ClientHello ------>
|
|
(with cookie)
|
|
<------ ServerHello
|
|
<------ Certificate
|
|
<------ ServerHelloDone
|
|
|
|
(WTP callout for AC authorization
|
|
occurs in CAPWAP Auth state)
|
|
|
|
Certificate*
|
|
ClientKeyExchange
|
|
CertificateVerify*
|
|
[<a href="#ref-ChangeCipherSpec">ChangeCipherSpec</a>]
|
|
Finished ------>
|
|
|
|
(AC callout for WTP authorization
|
|
occurs in CAPWAP Auth state)
|
|
|
|
[<a name="ref-ChangeCipherSpec" id="ref-ChangeCipherSpec">ChangeCipherSpec</a>]
|
|
<------ Finished
|
|
|
|
|
|
DTLS, as specified, provides its own retransmit timers with an
|
|
exponential back-off. However, DTLS will never terminate the
|
|
handshake due to non-responsiveness; instead, DTLS will continue to
|
|
increase its back-off timer period. Hence, timing out incomplete
|
|
DTLS handshakes is entirely the responsiblity of the CAPWAP module.
|
|
|
|
The DTLS implementation used by CAPWAP MUST support TLS Session
|
|
Resumption. Session resumption is used to establish the DTLS session
|
|
used for the data channel. The DTLS implementation on the WTP MUST
|
|
return some unique identifier to the CAPWAP module to enable
|
|
subsequent establishment of a DTLS-encrypted data channel, if
|
|
necessary.
|
|
|
|
<span class="h4"><a class="selflink" name="section-2.4.2" href="#section-2.4.2">2.4.2</a>. DTLS Session Establishment</span>
|
|
|
|
The WTP, either through the Discovery process, or through pre-
|
|
configuration, determines the AC to connect to. The WTP uses the
|
|
DTLSStart command to request that a secure connection be established
|
|
to the selected AC. Prior to initiation of the DTLS handshake, the
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 28]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-29" id="page-29" href="#page-29" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize
|
|
DTLS notification, the AC sets the WaitDTLS timer. If the
|
|
DTLSEstablished notification is not received prior to timer
|
|
expiration, the DTLS session is aborted by issuing the
|
|
DTLSAbortSession DTLS command. This notification causes the CAPWAP
|
|
module to transition to the Idle state. Upon receiving a
|
|
DTLSEstablished notification, the WaitDTLS timer is deactivated.
|
|
|
|
<span class="h4"><a class="selflink" name="section-2.4.3" href="#section-2.4.3">2.4.3</a>. DTLS Error Handling</span>
|
|
|
|
If the AC does not respond to any DTLS messages sent by the WTP, the
|
|
DTLS specification calls for the WTP to retransmit these messages.
|
|
If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession
|
|
command, causing DTLS to terminate the handshake and remove any
|
|
allocated session context. Note that DTLS MAY send a single TLS
|
|
Alert message to the AC to indicate session termination.
|
|
|
|
If the WTP does not respond to any DTLS messages sent by the AC, the
|
|
CAPWAP protocol allows for three possiblities, listed below. Note
|
|
that DTLS MAY send a single TLS Alert message to the AC to indicate
|
|
session termination.
|
|
|
|
o The message was lost in transit; in this case, the WTP will re-
|
|
transmit its last outstanding message, since it did not receive a
|
|
reply.
|
|
|
|
o The WTP sent a DTLS Alert, which was lost in transit; in this
|
|
case, the AC's WaitDTLS timer will expire, and the session will be
|
|
terminated.
|
|
|
|
o Communication with the WTP has completely failed; in this case,
|
|
the AC's WaitDTLS timer will expire, and the session will be
|
|
terminated.
|
|
|
|
The DTLS specification provides for retransmission of unacknowledged
|
|
requests. If retransmissions remain unacknowledged, the WaitDTLS
|
|
timer will eventually expire, at which time the CAPWAP component will
|
|
terminate the session.
|
|
|
|
If a cookie fails to validate, this could represent a WTP error, or
|
|
it could represent a DoS attack. Hence, AC resource utilization
|
|
SHOULD be minimized. The AC MAY log a message indicating the
|
|
failure, but SHOULD NOT attempt to reply to the WTP.
|
|
|
|
Since DTLS handshake messages are potentially larger than the maximum
|
|
record size, DTLS supports fragmenting of handshake messages across
|
|
multiple records. There are several potential causes of re-assembly
|
|
errors, including overlapping and/or lost fragments. The DTLS
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 29]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-30" id="page-30" href="#page-30" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
component MUST send a DTLSReassemblyFailure notification to the
|
|
CAPWAP component. Whether precise information is given along with
|
|
notification is an implementation issue, and hence is beyond the
|
|
scope of this document. Upon receipt of such an error, the CAPWAP
|
|
component SHOULD log an appropriate error message. Whether
|
|
processing continues or the DTLS session is terminated is
|
|
implementation dependent.
|
|
|
|
DTLS decapsulation errors consist of three types: decryption errors,
|
|
authentication errors, and malformed DTLS record headers. Since DTLS
|
|
authenticates the data prior to encapsulation, if decryption fails,
|
|
it is difficult to detect this without first attempting to
|
|
authenticate the packet. If authentication fails, a decryption error
|
|
is also likely, but not guaranteed. Rather than attempt to derive
|
|
(and require the implementation of) algorithms for detecting
|
|
decryption failures, decryption failures are reported as
|
|
authentication failures. The DTLS component MUST provide a
|
|
DTLSDecapFailure notification to the CAPWAP component when such
|
|
errors occur. If a malformed DTLS record header is detected, the
|
|
packets SHOULD be silently discarded, and the receiver MAY log an
|
|
error message.
|
|
|
|
There is currently only one encapsulation error defined: MTU
|
|
exceeded. As part of DTLS session establishment, the CAPWAP
|
|
component informs the DTLS component of the MTU size. This may be
|
|
dynamically modified at any time when the CAPWAP component sends the
|
|
DTLSMtuUpdate command to the DTLS component (see <a href="#section-2.3.2.1">Section 2.3.2.1</a>).
|
|
The DTLS component returns this notification to the CAPWAP component
|
|
whenever a transmission request will result in a packet which exceeds
|
|
the MTU.
|
|
|
|
<span class="h4"><a class="selflink" name="section-2.4.4" href="#section-2.4.4">2.4.4</a>. DTLS EndPoint Authentication and Authorization</span>
|
|
|
|
DTLS supports endpoint authentication with certificates or preshared
|
|
keys. The TLS algorithm suites for each endpoint authentication
|
|
method are described below.
|
|
|
|
<span class="h5"><a class="selflink" name="section-2.4.4.1" href="#section-2.4.4.1">2.4.4.1</a>. Authenticating with Certificates</span>
|
|
|
|
Note that only block ciphers are currently recommended for use with
|
|
DTLS. To understand the reasoning behind this, see [<a href="#ref-17" title=""The Design and Implementation of Datagram TLS"">17</a>]. At
|
|
present, the following algorithms MUST be supported when using
|
|
certificates for CAPWAP authentication:
|
|
|
|
o TLS_RSA_WITH_AES_128_CBC_SHA
|
|
|
|
The following algorithms SHOULD be supported when using certificates:
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 30]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-31" id="page-31" href="#page-31" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o TLS_DH_RSA_WITH_AES_128_CBC_SHA
|
|
|
|
The following algorithms MAY be supported when using certificates:
|
|
|
|
o TLS_RSA_WITH_AES_256_CBC_SHA
|
|
|
|
o TLS_DH_RSA_WITH_AES_256_CBC_SHA
|
|
|
|
<span class="h5"><a class="selflink" name="section-2.4.4.2" href="#section-2.4.4.2">2.4.4.2</a>. Authenticating with Preshared Keys</span>
|
|
|
|
Pre-shared keys present significant challenges from a security
|
|
perspective, and for that reason, their use is strongly discouraged.
|
|
Several methods for authenticating with preshared keys are defined
|
|
[<a href="#ref-6" title=""Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)"">6</a>], and we focus on the following two:
|
|
|
|
o PSK key exchange algorithm - simplest method, ciphersuites use
|
|
only symmetric key algorithms
|
|
|
|
o DHE_PSK key exchange algorithm - use a PSK to authenticate a
|
|
Diffie-Hellman exchange. These ciphersuites give some additional
|
|
protection against dictionary attacks and also provide Perfect
|
|
Forward Secrecy (PFS).
|
|
|
|
The first approach (plain PSK) is susceptible to passive dictionary
|
|
attacks; hence, while this alorithm MUST be supported, special care
|
|
should be taken when choosing that method. In particular, user-
|
|
readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD
|
|
be strongly discouraged.
|
|
|
|
The following cryptographic algorithms MUST be supported when using
|
|
preshared keys:
|
|
|
|
o TLS_PSK_WITH_AES_128_CBC_SHA
|
|
|
|
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
|
|
|
|
The following algorithms MAY be supported when using preshared keys:
|
|
|
|
o TLS_PSK_WITH_AES_256_CBC_SHA
|
|
|
|
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
|
|
|
|
<span class="h5"><a class="selflink" name="section-2.4.4.3" href="#section-2.4.4.3">2.4.4.3</a>. Certificate Usage</span>
|
|
|
|
Certificate authorization by the AC and WTP is required so that only
|
|
an AC may perform the functions of an AC and that only a WTP may
|
|
perform the functions of a WTP. This restriction of functions to the
|
|
AC or WTP requires that the certificates used by the AC MUST be
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 31]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-32" id="page-32" href="#page-32" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
distinguishable from the certificate used by the WTP. To accomplish
|
|
this differentiation, the x.509 certificates MUST include the
|
|
Extended Key Usage (EKU) certificate extension [<a href="#ref-4" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">4</a>].
|
|
|
|
The EKU field indicates one or more purposes for which a certificate
|
|
may be used. It is an essential part in authorization. Its syntax
|
|
is as follows:
|
|
|
|
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
|
|
|
|
KeyPurposeId ::= OBJECT IDENTIFIER
|
|
|
|
|
|
Here we define two KeyPurposeId values, one for the WTP and one for
|
|
the AC. Inclusion of one of these two values indicates a certificate
|
|
is authorized for use by a WTP or AC, respectively. These values are
|
|
formatted as id-kp fields.
|
|
|
|
id-kp OBJECT IDENTIFIER ::=
|
|
{ iso(1) identified-organization(3) dod(6) internet(1)
|
|
security(5) mechanisms(5) pkix(7) 3 }
|
|
|
|
id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
|
|
|
|
id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
|
|
|
|
|
|
|
|
For an AC, the id-kp-capwapAC EKU MUST be present in the certificate.
|
|
For a WTP, the id-kp-capwapWTP EKU MUST be present in the
|
|
certificate.
|
|
|
|
Part of the CAPWAP certificate validation process includes ensuring
|
|
that the proper EKU is included and allowing the CAPWAP session to be
|
|
established only if the extension properly represents the device.
|
|
|
|
The certificate common name (CN) for both the WTP and AC MUST be the
|
|
MAC address of that device. The MAC address MUST be formatted as
|
|
ASCII HEX, e.g. 01:23:45:67:89:ab.
|
|
|
|
ACs and WTPs SHOULD authorize (e.g. through access control lists)
|
|
certificates of devices to which they are connecting, based on the
|
|
MAC address and organizational information specified in the O and OU
|
|
fields. The identities specified in the certificates bind a
|
|
particular DTLS session to a specific pair of mutually-authenticated
|
|
and authorized MAC addresses.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 32]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-33" id="page-33" href="#page-33" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h5"><a class="selflink" name="section-2.4.4.4" href="#section-2.4.4.4">2.4.4.4</a>. PSK Usage</span>
|
|
|
|
When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST
|
|
contain the "PSK identity hint" field and the ClientKeyExchange
|
|
message MUST contain the "PSK identity" field. These fields are used
|
|
to help the WTP select the appropriate PSK for use with the AC, and
|
|
then indicate to the AC which key is being used. When PSKs are
|
|
provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for
|
|
the key MUST be specified.
|
|
|
|
The PSK Hint SHOULD uniquely identify the AC and the PSK Identity
|
|
SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints
|
|
and identities be the ASCII HEX-formatted MAC addresses of the
|
|
respective devices, since each pairwise combination of WTP and AC
|
|
SHOULD have a unique PSK. The PSK hint and identity SHOULD be
|
|
sufficient to perform authorization, as simply having knowledge of a
|
|
PSK does not necessarily imply authorization.
|
|
|
|
If a single PSK is being used for multiple devices on a CAPWAP
|
|
network, which is NOT RECOMMENDED, the PSK Hint and Identity can no
|
|
longer be a MAC address, so appropriate hints and identities SHOULD
|
|
be selected to identify the group of devices to which the PSK is
|
|
provisioned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 33]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-34" id="page-34" href="#page-34" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-3" href="#section-3">3</a>. CAPWAP Transport</span>
|
|
|
|
Communication between a WTP and an AC is established using the
|
|
standard UDP client/server model. The CAPWAP protocol supports both
|
|
UDP and UDP-Lite [<a href="#ref-11" title=""The Lightweight User Datagram Protocol (UDP-Lite)"">11</a>] transport protocols. The UDP protocol is used
|
|
with IPv4. When CAPWAP is used over IPv6, the UDP-Lite protocol is
|
|
used. This section describes how the CAPWAP protocol is carried over
|
|
IP and UDP/UDP-Lite transport protocols.
|
|
|
|
<span class="h3"><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. UDP Transport</span>
|
|
|
|
One of the CAPWAP protocol requirements is to allow a WTP to reside
|
|
behind a firewall and/or Network Address Translation (NAT) device.
|
|
Since a CAPWAP session is initiated by the WTP (client) to the well-
|
|
known UDP port of the AC (server), the use of UDP is a logical
|
|
choice. The UDP checksum field in CAPWAP packets MUST be set to
|
|
zero.
|
|
|
|
CAPWAP protocol control packets sent from the WTP to the AC use the
|
|
CAPWAP control channel, as defined in <a href="#section-1.4">Section 1.4</a>. The CAPWAP
|
|
control port at the AC is the well known UDP port [to be IANA
|
|
assigned]. The CAPWAP control port at the WTP can be any port
|
|
selected by the WTP.
|
|
|
|
CAPWAP protocol data packets sent from the WTP to the AC use the
|
|
CAPWAP data channel, as defined in <a href="#section-1.4">Section 1.4</a>. The CAPWAP data port
|
|
at the AC is the well known UDP port [to be IANA assigned]. The
|
|
CAPWAP data port at the WTP can be any port selected by the WTP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. UDP-Lite Transport</span>
|
|
|
|
When CAPWAP is run over IPv6, UDP-Lite is used as the transport
|
|
protocol, reducing the checksum processing required for each packet
|
|
(compared to UDP and IPv6). When UDP-Lite is used, the checksum
|
|
field MUST have a coverage of 8 [<a href="#ref-11" title=""The Lightweight User Datagram Protocol (UDP-Lite)"">11</a>].
|
|
|
|
UDP-Lite uses the same port assignments as UDP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. AC Discovery</span>
|
|
|
|
The AC discovery phase allows the WTP to determine which ACs are
|
|
available, and chose the best AC with which to establish a CAPWAP
|
|
session. The discovery phase occurs when the WTP enters the optional
|
|
Discovery state. A WTP does not need to complete the AC Discovery
|
|
phase if it uses a pre-configured AC. This section details the
|
|
mechanism used by a WTP to dynamically discover candidate ACs.
|
|
|
|
A WTP and an AC will frequently not reside in the same IP subnet
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 34]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-35" id="page-35" href="#page-35" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
(broadcast domain). When this occurs, the WTP must be capable of
|
|
discovering the AC, without requiring that multicast services are
|
|
enabled in the network.
|
|
|
|
When the WTP attempts to establish communication with an AC, it sends
|
|
the Discovery Request message and receives the Discovery Response
|
|
message from the AC(s). The WTP MUST send the Discovery Request
|
|
message to either the limited broadcast IP address (255.255.255.255),
|
|
a well known multicast address or to the unicast IP address of the
|
|
AC. For IPv6 networks, since broadcast does not exist, the use of
|
|
"All ACs multicast address" is used instead. Upon receipt of the
|
|
Discovery Request message, the AC sends a Discovery Response message
|
|
to the unicast IP address of the WTP, regardless of whether the
|
|
Discovery Request message was sent as a broadcast, multicast or
|
|
unicast message.
|
|
|
|
WTP use of a limited IP broadcast, multicast or unicast IP address is
|
|
implementation dependent.
|
|
|
|
When a WTP transmits a Discovery Request message to a unicast
|
|
address, the WTP must first obtain the IP address of the AC. Any
|
|
static configuration of an AC's IP address on the WTP non-volatile
|
|
storage is implementation dependent. However, additional dynamic
|
|
schemes are possible, for example:
|
|
|
|
DHCP: See [<a href="#ref-13" title=""CAPWAP Access Controller DHCP Option"">13</a>] for more information on the use of DHCP to discover
|
|
AC IP addresses.
|
|
|
|
DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or
|
|
more AC addresses.
|
|
|
|
An AC MAY also communicate alternative ACs to the WTP within the
|
|
Discovery Response message through the AC IPv4 List (see
|
|
<a href="#section-4.6.2">Section 4.6.2</a>) and AC IPv6 List (see <a href="#section-4.6.2">Section 4.6.2</a>). The addresses
|
|
provided in these two message elements are intended to help the WTP
|
|
discover additional ACs through means other than those listed above.
|
|
|
|
The AC Name with Index message element (see <a href="#section-4.6.5">Section 4.6.5</a>), is used
|
|
to communicate a list of preferred ACs to the WTP. The WTP SHOULD
|
|
attempt to utilize the ACs listed in the order provided by the AC.
|
|
The Name to IP Address mapping is handled via the Discovery message
|
|
exchange, in which the ACs provide their identity in the AC Name (see
|
|
<a href="#section-4.6.4">Section 4.6.4</a>) message element in the Discovery Response message.
|
|
|
|
Once the WTP has received Discovery Response messages from the
|
|
candidate ACs, it MAY use other factors to determine the preferred
|
|
AC. For instance, each binding defines a WTP Radio Information
|
|
message element (see <a href="#section-2.1">Section 2.1</a>), which the AC includes in Discovery
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 35]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-36" id="page-36" href="#page-36" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Response messages. The presence of one or more of these message
|
|
elements is used to identify the CAPWAP bindings supported by the AC.
|
|
A WTP MAY connect to an AC based on the supported bindings
|
|
advertised.
|
|
|
|
<span class="h3"><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Fragmentation/Reassembly</span>
|
|
|
|
While fragmentation and reassembly services are provided by IP, the
|
|
CAPWAP protocol also provides such services. Environments where the
|
|
CAPWAP protocol is used involve firewall, NAT and "middle box"
|
|
devices, which tend to drop IP fragments to minimize possible DoS
|
|
attacks. By providing fragmentation and reassembly at the
|
|
application layer, any fragmentation required due to the tunneling
|
|
component of the CAPWAP protocol becomes transparent to these
|
|
intermediate devices. Consequently, the CAPWAP protocol can be used
|
|
in any network configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 36]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-37" id="page-37" href="#page-37" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-4" href="#section-4">4</a>. CAPWAP Packet Formats</span>
|
|
|
|
This section contains the CAPWAP protocol packet formats. A CAPWAP
|
|
protocol packet consists of one or more CAPWAP Transport Layer packet
|
|
headers followed by a CAPWAP message. The CAPWAP message can be
|
|
either of type Control or Data, where Control packets carry
|
|
signaling, and Data packets carry user payloads. The CAPWAP frame
|
|
formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP
|
|
Data and Control packets are defined below.
|
|
|
|
The CAPWAP Control protocol includes two messages that are never
|
|
protected by DTLS: the Discovery Request message and the Discovery
|
|
Response message. These messages need to be in the clear to allow
|
|
the CAPWAP protocol to properly identify and process them. The
|
|
format of these packets are as follows:
|
|
|
|
CAPWAP Control Packet (Discovery Request/Response):
|
|
+-------------------------------------------+
|
|
| IP | UDP | CAPWAP | Control | Message |
|
|
| Hdr | Hdr | Header | Header | Element(s) |
|
|
+-------------------------------------------+
|
|
|
|
All other CAPWAP control protocol messages MUST be protected via the
|
|
DTLS protocol, which ensures that the packets are both authenticated
|
|
and encrypted. These packets include the CAPWAP DTLS Header, which
|
|
is described in <a href="#section-4.2">Section 4.2</a>. The format of these packets is as
|
|
follows:
|
|
|
|
CAPWAP Control Packet (DTLS Security Required):
|
|
+------------------------------------------------------------------+
|
|
| IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS |
|
|
| Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr |
|
|
+------------------------------------------------------------------+
|
|
\---------- authenticated -----------/
|
|
\------------- encrypted ------------/
|
|
|
|
The CAPWAP protocol allows optional protection of data packets, using
|
|
DTLS. Use of data packet protection is determined by AC policy.
|
|
When DTLS is utilized, the optional CAPWAP DTLS Header is present,
|
|
which is described in <a href="#section-4.2">Section 4.2</a>. The format of CAPWAP data packets
|
|
is shown below:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 37]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-38" id="page-38" href="#page-38" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
CAPWAP Plain Text Data Packet :
|
|
+-------------------------------+
|
|
| IP | UDP | CAPWAP | Wireless |
|
|
| Hdr | Hdr | Header | Payload |
|
|
+-------------------------------+
|
|
|
|
DTLS Secured CAPWAP Data Packet:
|
|
+--------------------------------------------------------+
|
|
| IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
|
|
| Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr |
|
|
+--------------------------------------------------------+
|
|
\------ authenticated -----/
|
|
\------- encrypted --------/
|
|
|
|
UDP Header: All CAPWAP packets are encapsulated within either UDP,
|
|
or UDP-Lite when used over IPv6. <a href="#section-3">Section 3</a> defines the specific
|
|
UDP or UDP-Lite usage.
|
|
|
|
CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are
|
|
prefixed with the CAPWAP DTLS header (see <a href="#section-4.2">Section 4.2</a>).
|
|
|
|
DTLS Header: The DTLS header provides authentication and encryption
|
|
services to the CAPWAP payload it encapsulates. This protocol is
|
|
defined in <a href="./rfc4347">RFC 4347</a> [<a href="#ref-8" title=""Datagram Transport Layer Security"">8</a>].
|
|
|
|
CAPWAP Header: All CAPWAP protocol packets use a common header that
|
|
immediately follows the CAPWAP preamble or DTLS header. The
|
|
CAPWAP Header is defined in <a href="#section-4.3">Section 4.3</a>.
|
|
|
|
Wireless Payload: A CAPWAP protocol packet that contains a wireless
|
|
payload is a CAPWAP data packet. The CAPWAP protocol does not
|
|
specify the format of the wireless payload, which is defined by
|
|
the appropriate wireless standard. Additional information is in
|
|
<a href="#section-4.4">Section 4.4</a>.
|
|
|
|
Control Header: The CAPWAP protocol includes a signalling component,
|
|
known as the CAPWAP control protocol. All CAPWAP control packets
|
|
include a Control Header, which is defined in <a href="#section-4.5.1">Section 4.5.1</a>.
|
|
CAPWAP data packets do not contain a Control Header field.
|
|
|
|
Message Elements: A CAPWAP Control packet includes one or more
|
|
message elements, which are found immediately following the
|
|
Control Header. These message elements are in a Type/Length/value
|
|
style header, defined in <a href="#section-4.6">Section 4.6</a>.
|
|
|
|
A CAPWAP implementation MUST be capable of receiving a reassembled
|
|
CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY
|
|
indicate that it supports a higher maximum message length, by
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 38]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-39" id="page-39" href="#page-39" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
including the Maximum Message Length message element, see
|
|
<a href="#section-4.6.29">Section 4.6.29</a> in the Join Request message or the Join Response
|
|
message.
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. CAPWAP Preamble</span>
|
|
|
|
The CAPWAP preamble is common to all CAPWAP transport headers and is
|
|
used to identify the header type that immediately follows. The
|
|
reason for this header is to avoid needing to perform byte
|
|
comparisons in order to guess whether the frame is DTLS encrypted or
|
|
not. It also provides an extensibility framework that can be used to
|
|
support additional transport types. The format of the preamble is as
|
|
follows:
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
|Version| Type |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Version: A 4 bit field which contains the version of CAPWAP used in
|
|
this packet. The value for this specification is zero (0).
|
|
|
|
Payload Type: A 4 bit field which specifies the payload type that
|
|
follows the UDP header. The following values are supported:
|
|
|
|
0 - CAPWAP Header. The CAPWAP Header (see <a href="#section-4.3">Section 4.3</a>)
|
|
immediately follows the UDP header. If the packet is received
|
|
on the CAPWAP data channel, the CAPWAP stack MUST treat the
|
|
packet as a clear text CAPWAP data packet. If received on the
|
|
CAPWAP control channel, the CAPWAP stack MUST treat the packet
|
|
as a clear text CAPWAP control packet. If the control packet
|
|
is not a Discovery Request or Discovery Response packet, the
|
|
packet MUST be dropped.
|
|
|
|
1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet,
|
|
immediately follows the UDP header (see <a href="#section-4.2">Section 4.2</a>).
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. CAPWAP DTLS Header</span>
|
|
|
|
The CAPWAP DTLS Header is used to identify the packet as a DTLS
|
|
encrypted packet. The first eight bits includes the common CAPWAP
|
|
Preamble. The remaining 24 bits are padding to ensure 4 byte
|
|
alignment, and MAY be used in a future version of the protocol. The
|
|
DTLS packet [<a href="#ref-8" title=""Datagram Transport Layer Security"">8</a>] always immediately follows this header. The format
|
|
of the CAPWAP DTLS Header is as follows:
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 39]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-40" id="page-40" href="#page-40" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|CAPWAP Preamble| Reserved |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
CAPWAP Preamble: The CAPWAP Preamble is defined in <a href="#section-4.1">Section 4.1</a>. The
|
|
CAPWAP Preamble's Payload Type field MUST be set to one (1).
|
|
|
|
Reserved: The 24-bit field is reserved 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.
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. CAPWAP Header</span>
|
|
|
|
All CAPWAP protocol messages are encapsulated using a common header
|
|
format, regardless of the CAPWAP Control or CAPWAP Data transport
|
|
used to carry the messages. However, certain flags are not
|
|
applicable for a given transport. Refer to the specific transport
|
|
section in order to determine which flags are valid.
|
|
|
|
Note that the optional fields defined in this section MUST be present
|
|
in the precise order shown below.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Fragment ID | Frag Offset |Rsvd |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| (optional) Radio MAC Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| (optional) Wireless Specific Information |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Payload .... |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
CAPWAP Preamble: The CAPWAP Preamble is defined in <a href="#section-4.1">Section 4.1</a>. The
|
|
CAPWAP Preamble's Payload Type field MUST be set to zero (0). If
|
|
the CAPWAP DTLS Header is present, the version number in both
|
|
CAPWAP Preambles MUST match. The reason for this duplicate field
|
|
is to avoid any possible tampering of the version field in the
|
|
preamble which is not encrypted or authenticated.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 40]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-41" id="page-41" href="#page-41" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
HLEN: A 5 bit field containing the length of the CAPWAP transport
|
|
header in 4 byte words (Similar to IP header length). This length
|
|
includes the optional headers.
|
|
|
|
RID: A 5 bit field which contains the Radio ID number for this
|
|
packet. Given that MAC Addresses are not necessarily unique
|
|
across physical radios in a WTP, the Radio Identifier (RID) field
|
|
is used to indiciate which physical radio the message is
|
|
associated with.
|
|
|
|
WBID: A 5 bit field which is the wireless binding identifier. The
|
|
identifier will indicate the type of wireless packet type
|
|
associated with the radio. The following values are defined:
|
|
|
|
1 - IEEE 802.11
|
|
|
|
2 - IEEE 802.16
|
|
|
|
3 - EPCGlobal
|
|
|
|
T: The Type 'T' bit indicates the format of the frame being
|
|
transported in the payload. When this bit is set to one (1), the
|
|
payload has the native frame format indicated by the WBID field.
|
|
When this bit is zero (0) the payload is an IEEE 802.3 frame.
|
|
|
|
F: The Fragment 'F' bit indicates whether this packet is a fragment.
|
|
When this bit is one (1), the packet is a fragment and MUST be
|
|
combined with the other corresponding fragments to reassemble the
|
|
complete information exchanged between the WTP and AC.
|
|
|
|
L: The Last 'L' bit is valid only if the 'F' bit is set and indicates
|
|
whether the packet contains the last fragment of a fragmented
|
|
exchange between WTP and AC. When this bit is 1, the packet is
|
|
the last fragment. When this bit is 0, the packet is not the last
|
|
fragment.
|
|
|
|
W: The Wireless 'W' bit is used to specify whether the optional
|
|
Wireless Specific Information field is present in the header. A
|
|
value of one (1) is used to represent the fact that the optional
|
|
header is present.
|
|
|
|
M: The M bit is used to indicate that the Radio MAC Address optional
|
|
header is present. This is used to communicate the MAC address of
|
|
the receiving radio.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 41]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-42" id="page-42" href="#page-42" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep
|
|
Alive packet. This packet is used to map the data channel to the
|
|
control channel for the specified Session ID and to maintain
|
|
freshness of the data channel. The K bit MUST NOT be set for data
|
|
packets containing user data.
|
|
|
|
Flags: A set of reserved bits for future flags in the CAPWAP header.
|
|
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.
|
|
|
|
Fragment ID: A 16 bit field whose value is assigned to each group of
|
|
fragments making up a complete set. The fragment ID space is
|
|
managed individually for every WTP/AC pair. The value of Fragment
|
|
ID is incremented with each new set of fragments. The Fragment ID
|
|
wraps to zero after the maximum value has been used to identify a
|
|
set of fragments.
|
|
|
|
Fragment Offset: A 13 bit field that indicates where in the payload
|
|
this fragment belongs during re-assembly. This field is valid
|
|
when the 'F' bit is set to 1. The fragment offset is measured in
|
|
units of 8 octets (64 bits). The first fragment has offset zero.
|
|
Note the CAPWAP protocol does not allow for overlapping fragments.
|
|
|
|
Reserved: The 3-bit field is reserved 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.
|
|
|
|
Radio MAC Address: This optional field contains the MAC address of
|
|
the radio receiving the packet. This is useful in packets sent
|
|
from the WTP to the AC, when the native wireless frame format is
|
|
converted to 802.3 by the WTP. This field is only present if the
|
|
'M' bit is set. The HLEN field assumes 4 byte alignment, and this
|
|
field MUST be padded with zeroes (0x00) if it is not 4 byte
|
|
aligned.
|
|
|
|
The field contains the basic format:
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Length | MAC Address
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 42]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-43" id="page-43" href="#page-43" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Length: The length of the MAC Address field [<a href="#ref-18" title=""Guidelines for use of a 48-bit Extended Unique Identifier"">18</a>] [<a href="#ref-19" title=""GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY"">19</a>].
|
|
|
|
MAC Address: The MAC Address of the receiving radio.
|
|
|
|
Wireless Specific Information: This optional field contains
|
|
technology specific information that may be used to carry per
|
|
packet wireless information. This field is only present if the
|
|
'W' bit is set. The HLEN field assumes 4 byte alignment, and this
|
|
field MUST be padded with zeroes (0x00) if it is not 4 byte
|
|
aligned.
|
|
|
|
The Wireless Specific Information field uses the following format:
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Wireless ID | Length | Data
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Wireless ID: The wireless binding identifier. The following
|
|
values are defined:
|
|
|
|
1 - IEEE 802.11
|
|
|
|
2 - IEEE 802.16
|
|
|
|
3 - EPCGlobal
|
|
|
|
Length: The length of the data field
|
|
|
|
Data: Wireless specific information, defined by the wireless
|
|
specific binding.
|
|
|
|
Payload: This field contains the header for a CAPWAP Data Message or
|
|
CAPWAP Control Message, followed by the data contained in the
|
|
message.
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.4" href="#section-4.4">4.4</a>. CAPWAP Data Messages</span>
|
|
|
|
There are two different types of CAPWAP data packets, CAPWAP Data
|
|
Channel Keep Alive packets and Data Payload packets. The first is
|
|
used by the WTP to synchronize the control and data channels, and to
|
|
maintain freshness of the data channel. The second is used to
|
|
transmit user payloads between the AC and WTP. This section
|
|
describes both types of CAPWAP data packet formats.
|
|
|
|
Both CAPWAP data messages are transmitted on the CAPWAP data channel.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 43]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-44" id="page-44" href="#page-44" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.4.1" href="#section-4.4.1">4.4.1</a>. CAPWAP Data Keepalive</span>
|
|
|
|
The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP
|
|
control channel with the data channel, and to maintain freshness of
|
|
the data channel, ensuring that the channel is still functioning.
|
|
The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP
|
|
when the DataChannelKeepAlive timer expires. When the CAPWAP Data
|
|
Channel Keep Alive packet is transmitted, the WTP sets the
|
|
DataChannelDeadInterval timer.
|
|
|
|
In the CAPWAP Data Channel Keep Alive packet, all of the fields in
|
|
the CAPWAP header, except the HLEN field and the K bit, are set to
|
|
zero upon transmission. Upon receiving a CAPWAP Data Channel Keep
|
|
Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive
|
|
packet back to the WTP. The contents of the transmitted packet are
|
|
identical to the contents of the received packet.
|
|
|
|
Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP
|
|
cancels the DataChannelDeadInterval timer and resets the
|
|
DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive
|
|
packet is retransmitted by the WTP in the same manner as the CAPWAP
|
|
control messages. If the DataChannelDeadInterval timer expires, the
|
|
WTP tears down the control DTLS session, and the data DTLS session if
|
|
one existed.
|
|
|
|
The CAPWAP Data Channel Keep Alive packet contains the following
|
|
payload immediately following the CAPWAP Header (see <a href="#section-4.3">Section 4.3</a>)
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Message Element Length | Message Element [0..N] ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Message Element Length: The Length field indicates the number of
|
|
bytes following the CAPWAP Header.
|
|
|
|
Message Element[0..N]: The message element(s) carry the information
|
|
pertinent to each of the CAPWAP Data Keepalive message. The
|
|
following message elements MUST be present in this CAPWAP message:
|
|
|
|
Session ID, see <a href="#section-4.6.35">Section 4.6.35</a>
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Data Payload</span>
|
|
|
|
A CAPWAP protocol Data Payload packet encapsulates a forwarded
|
|
wireless frame. The CAPWAP protocol defines two different modes of
|
|
encapsulation; IEEE 802.3 and native wireless. IEEE 802.3
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 44]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-45" id="page-45" href="#page-45" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
encapsulation requires that the bridging function be performed in the
|
|
WTP. An IEEE 802.3 encapsulated user payload frame has the following
|
|
format:
|
|
|
|
+------------------------------------------------------+
|
|
| IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
|
|
+------------------------------------------------------+
|
|
|
|
The CAPWAP protocol also defines the native wireless encapsulation
|
|
mode. The format of the encapsulated CAPWAP data frame is subject to
|
|
the rules defined by the specific wireless technology binding. Each
|
|
wireless technology binding MUST contain a section entitled "Payload
|
|
Encapsulation", which defines the format of the wireless payload that
|
|
is encapsulated within CAPWAP Data packets.
|
|
|
|
If the encapsulated frame would exceed the transport layer's MTU, the
|
|
sender is responsible for fragmentation of the frame, as specified in
|
|
<a href="#section-3.4">Section 3.4</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.4.3" href="#section-4.4.3">4.4.3</a>. Establishment of a DTLS Data Channel</span>
|
|
|
|
If the AC and WTP are configured to tunnel the data channel over
|
|
DTLS, the proper DTLS session must be initiated. To avoid having to
|
|
reauthenticate and reauthorize an AC and WTP, the DTLS data channel
|
|
MUST be initiated using the TLS session resumption feature [<a href="#ref-7" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">7</a>].
|
|
|
|
When establishing the DTLS-encrypted data channel, the WTP MUST
|
|
provide the identifier returned during the initialization of the
|
|
control channel to the DTLS component so it can perform the
|
|
resumption using the proper session information.
|
|
|
|
The AC DTLS implementation MUST NOT accept a session resumption
|
|
request for a DTLS session in which the control channel for the
|
|
session has been torn down.
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.5" href="#section-4.5">4.5</a>. CAPWAP Control Messages</span>
|
|
|
|
The CAPWAP Control protocol provides a control channel between the
|
|
WTP and the AC. Control messages are divided into the following
|
|
message types:
|
|
|
|
Discovery: CAPWAP Discovery messages are used to identify potential
|
|
ACs, their load and capabilities.
|
|
|
|
Join: CAPWAP Join messages are used by a WTP to request service from
|
|
an AC, and for the AC to respond to the WTP.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 45]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-46" id="page-46" href="#page-46" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Control Channel Management: CAPWAP control channel management
|
|
messages are used to maintain the control channel.
|
|
|
|
WTP Configuration Management: The WTP Configuration messages are
|
|
used by the AC to deliver a specific configuration to the WTP.
|
|
Messages which retrieve statistics from a WTP are also included in
|
|
WTP Configuration Management.
|
|
|
|
Station Session Management: Station Session Management messages are
|
|
used by the AC to deliver specific station policies to the WTP.
|
|
|
|
Device Management Operations: Device management operations are used
|
|
to request and deliver a firmware image to the WTP.
|
|
|
|
Binding Specific CAPWAP Management Messages: Messages in this
|
|
category are used by the AC and the WTP to exchange protocol-
|
|
specific CAPWAP management messages. These messages may or may
|
|
not be used to change the link state of a station.
|
|
|
|
Discovery, Join, Control Channel Management, WTP Configuration
|
|
Management and Station Session Management CAPWAP control messages
|
|
MUST be implemented. Device Management Operations messages MAY be
|
|
implemented.
|
|
|
|
CAPWAP control messages sent from the WTP to the AC indicate that the
|
|
WTP is operational, providing an implicit keep-alive mechanism for
|
|
the WTP. The Control Channel Management Echo Request and Echo
|
|
Response messages provide an explicit keep-alive mechanism when other
|
|
CAPWAP control messages are not exchanged.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.5.1" href="#section-4.5.1">4.5.1</a>. Control Message Format</span>
|
|
|
|
All CAPWAP control messages are sent encapsulated within the CAPWAP
|
|
header (see <a href="#section-4.3">Section 4.3</a>). Immediately following the CAPWAP header,
|
|
is the control header, which has the following format:
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Message Type |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Seq Num | Msg Element Length | Flags |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Msg Element [0..N] ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 46]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-47" id="page-47" href="#page-47" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h5"><a class="selflink" name="section-4.5.1.1" href="#section-4.5.1.1">4.5.1.1</a>. Message Type</span>
|
|
|
|
The Message Type field identifies the function of the CAPWAP control
|
|
message. The Message Type field is comprised of an IANA Enterprise
|
|
Number and an enterprise specific message type number. The first
|
|
three octets contain the enterprise number in network byte order,
|
|
with zero used for CAPWAP protocol defined message types and the IEEE
|
|
802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11
|
|
technology specific message types. The last octet is the enterprise
|
|
specific message type number, which has a range from 0 to 255.
|
|
|
|
The message type field is defined as:
|
|
|
|
Message Type =
|
|
IANA Enterprise Number * 256 +
|
|
Enterprise Specific Message Type Number
|
|
|
|
The CAPWAP protocol reliability mechanism requires that messages be
|
|
defined in pairs, consisting of both a Request and a Response
|
|
message. The Response message MUST acknowledge the Request message.
|
|
The assignment of CAPWAP control Message Type Values always occurs in
|
|
pairs. All Request messages have odd numbered Message Type Values,
|
|
and all Response messages have even numbered Message Type Values.
|
|
The Request value MUST be assigned first. As an example, assigning a
|
|
Message Type Value of 3 for a Request message and 4 for a Response
|
|
message is valid, while assigning a Message Type Value of 4 for a
|
|
Response message and 5 for the corresponding Request message is
|
|
invalid.
|
|
|
|
When a WTP or AC receives a message with a Message Type Value field
|
|
that is not recognized and is an odd number, the number in the
|
|
Message Type Value Field is incremented by one, and a Response
|
|
message with a Message Type Value field containing the incremented
|
|
value and containing the Result Code message element with the value
|
|
(Unrecognized Request) is returned to the sender of the received
|
|
message. If the unknown message type is even, the message is
|
|
ignored.
|
|
|
|
The valid values for CAPWAP Control Message Types are specified in
|
|
the table below:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 47]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-48" id="page-48" href="#page-48" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
CAPWAP Control Message Message Type
|
|
Value
|
|
Discovery Request 1
|
|
Discovery Response 2
|
|
Join Request 3
|
|
Join Response 4
|
|
Configuration Status 5
|
|
Configuration Status Response 6
|
|
Configuration Update Request 7
|
|
Configuration Update Response 8
|
|
WTP Event Request 9
|
|
WTP Event Response 10
|
|
Change State Event Request 11
|
|
Change State Event Response 12
|
|
Echo Request 13
|
|
Echo Response 14
|
|
Image Data Request 15
|
|
Image Data Response 16
|
|
Reset Request 17
|
|
Reset Response 18
|
|
Primary Discovery Request 19
|
|
Primary Discovery Response 20
|
|
Data Transfer Request 21
|
|
Data Transfer Response 22
|
|
Clear Configuration Request 23
|
|
Clear Configuration Response 24
|
|
Station Configuration Request 25
|
|
Station Configuration Response 26
|
|
|
|
<span class="h5"><a class="selflink" name="section-4.5.1.2" href="#section-4.5.1.2">4.5.1.2</a>. Sequence Number</span>
|
|
|
|
The Sequence Number Field is an identifier value used to match
|
|
Request and Response packets. When a CAPWAP packet with a Request
|
|
Message Type Value is received, the value of the Sequence Number
|
|
field is copied into the corresponding Response message.
|
|
|
|
When a CAPWAP control message is sent, the sender's internal sequence
|
|
number counter is monotonically incremented, ensuring that no two
|
|
pending Request messages have the same Sequence Number. The Sequence
|
|
Number field wraps back to zero.
|
|
|
|
<span class="h5"><a class="selflink" name="section-4.5.1.3" href="#section-4.5.1.3">4.5.1.3</a>. Message Element Length</span>
|
|
|
|
The Length field indicates the number of bytes following the Sequence
|
|
Number field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 48]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-49" id="page-49" href="#page-49" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h5"><a class="selflink" name="section-4.5.1.4" href="#section-4.5.1.4">4.5.1.4</a>. Flags</span>
|
|
|
|
The Flags field MUST be set to zero.
|
|
|
|
<span class="h5"><a class="selflink" name="section-4.5.1.5" href="#section-4.5.1.5">4.5.1.5</a>. Message Element[0..N]</span>
|
|
|
|
The message element(s) carry the information pertinent to each of the
|
|
control message types. Every control message in this specification
|
|
specifies which message elements are permitted.
|
|
|
|
When a WTP or AC receives a CAPWAP message without a message element
|
|
that is specified as mandatory for the CAPWAP message, then the
|
|
CAPWAP message is discarded. If the received message was a Request
|
|
message for which the corresponding Response message carries message
|
|
elements, then a corresponding Response message with a Result Code
|
|
message element indicating "Failure - Missing Mandatory Message
|
|
Element" is returned to the sender.
|
|
|
|
When a WTP or AC receives a CAPWAP message with a message element
|
|
that the WTP or AC does not recognize, the CAPWAP message is
|
|
discarded. If the received message was a Request message for which
|
|
the corresponding Response message carries message elements, then a
|
|
corresponding Response message with a Result Code message element
|
|
indicating "Failure - Unrecognized Message Element" and one or more
|
|
Returned Message Element message elements is included, containing the
|
|
unrecognized message element(s).
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.5.2" href="#section-4.5.2">4.5.2</a>. Control Message Quality of Service</span>
|
|
|
|
It is recommended that CAPWAP control messages be sent by both the AC
|
|
and the WTP with an appropriate Quality of Service precedence value,
|
|
ensuring that congestion in the network minimizes occurrences of
|
|
CAPWAP control channel disconnects. Therefore, a Quality of Service
|
|
enabled CAPWAP device SHOULD use the following values:
|
|
|
|
802.1P: The precedence value of 7 SHOULD be used.
|
|
|
|
DSCP: The DSCP tag value of 46 SHOULD be used.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.5.3" href="#section-4.5.3">4.5.3</a>. Retransmissions</span>
|
|
|
|
The CAPWAP control protocol operates as a reliable transport. For
|
|
each Request message, a Response message is defined, which is used to
|
|
acknowledge receipt of the Request message. In addition, the control
|
|
header Sequence Number field is used to pair the Request and Response
|
|
messages (see <a href="#section-4.5.1">Section 4.5.1</a>).
|
|
|
|
Response messages are not explicitly acknowledged, therefore if a
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 49]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-50" id="page-50" href="#page-50" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Response message is not received, the original Request message is
|
|
retransmitted. Implementations MAY cache Response messages to
|
|
respond to a retransmitted Request messages with minimal local
|
|
processing. Retransmitted Request messages MUST NOT be altered by
|
|
the sender. The sender MUST assume that the original Request message
|
|
was processed, but that the Response message was lost. Any
|
|
alterations to the original Request message MUST have a new Sequence
|
|
Number, and be treated as a new Request message by the receiver.
|
|
|
|
After transmitting a Request message, the RetransmitInterval (see
|
|
<a href="#section-4.7">Section 4.7</a>) timer and MaxRetransmit (see <a href="#section-4.8">Section 4.8</a>) variable are
|
|
used to determine if the original Request message needs to be
|
|
retransmitted. The RetransmitInterval timer is used the first time
|
|
the Request is retransmitted. The timer is then doubled every
|
|
subsequent time the same Request message is retransmitted, up to
|
|
MaxRetransmit but no more than half the EchoInterval timer (see
|
|
<a href="#section-4.7.5">Section 4.7.5</a>). Response messages are not subject to these timers.
|
|
|
|
When a Request message is retransmitted, it MUST be re-encrypted via
|
|
the DTLS stack. If the peer had received the Request message, and
|
|
the corresponding Response message was lost, it is necessary to
|
|
ensure that retransmitted Request messages are not identified as
|
|
replays by the DTLS stack. Similarly, any cached Response messages
|
|
that are retransmitted as a result of receiving a retransmitted
|
|
Request message MUST be re-encrypted via DTLS.
|
|
|
|
Duplicate Response messages, identified by the Sequence Number field
|
|
in the CAPWAP control message header, SHOULD be discarded upon
|
|
receipt.
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.6" href="#section-4.6">4.6</a>. CAPWAP Protocol Message Elements</span>
|
|
|
|
This section defines the CAPWAP Protocol message elements which are
|
|
included in CAPWAP protocol control messages.
|
|
|
|
Message elements are used to carry information needed in control
|
|
messages. Every message element is identified by the Type Value
|
|
field, defined below. The total length of the message elements is
|
|
indicated in the message element Length field.
|
|
|
|
All of the message element definitions in this document use a diagram
|
|
similar to the one below in order to depict its format. Note that to
|
|
simplify this specification, these diagrams do not include the header
|
|
fields (Type and Length). The header field values are defined in the
|
|
message element descriptions.
|
|
|
|
Unless otherwise specified, a control message that lists a set of
|
|
supported (or expected) message elements MUST not expect the message
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 50]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-51" id="page-51" href="#page-51" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
elements to be in any specific order. The sender MAY include the
|
|
message elements in any order. Unless otherwise noted, one message
|
|
element of each type is present in a given control message.
|
|
|
|
Additional message elements may be defined in separate IETF
|
|
documents.
|
|
|
|
The format of a message element uses the TLV format shown here:
|
|
|
|
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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value ... |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
The 16 bit Type field identifies the information carried in the Value
|
|
field and Length (16 bits) indicates the number of bytes in the Value
|
|
field. Type field values are allocated as follows:
|
|
|
|
Usage Type Values
|
|
|
|
CAPWAP Protocol Message Elements 1-1023
|
|
IEEE 802.11 Message Elements 1024-2047
|
|
IEEE 802.16 Message Elements 2048 - 3071
|
|
EPCGlobal Message Elements 3072 - 4095
|
|
Reserved for Future Use 4096 - 65024
|
|
|
|
The table below lists the CAPWAP protocol Message Elements and their
|
|
Type values.
|
|
|
|
CAPWAP Message Element Type Value
|
|
|
|
AC Descriptor 1
|
|
AC IPv4 List 2
|
|
AC IPv6 List 3
|
|
AC Name 4
|
|
AC Name with Index 5
|
|
AC Timestamp 6
|
|
Add MAC ACL Entry 7
|
|
Add Station 8
|
|
Add Static MAC ACL Entry 9
|
|
CAPWAP Control IPV4 Address 10
|
|
CAPWAP Control IPV6 Address 11
|
|
CAPWAP Timers 12
|
|
Data Transfer Data 13
|
|
Data Transfer Mode 14
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 51]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-52" id="page-52" href="#page-52" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Decryption Error Report 15
|
|
Decryption Error Report Period 16
|
|
Delete MAC ACL Entry 17
|
|
Delete Station 18
|
|
Delete Static MAC ACL Entry 19
|
|
Discovery Type 20
|
|
Duplicate IPv4 Address 21
|
|
Duplicate IPv6 Address 22
|
|
Idle Timeout 23
|
|
Image Data 24
|
|
Image Identifier 25
|
|
Image Info 26
|
|
Initiate Download 27
|
|
Location Data 28
|
|
Maximum Message Length 29
|
|
MTU Discovery Padding 30
|
|
Radio Administrative State 31
|
|
Radio Operational State 32
|
|
Result Code 33
|
|
Returned Message Element 34
|
|
Session ID 35
|
|
Statistics Timer 36
|
|
Vendor Specific Payload 37
|
|
WTP Board Data 38
|
|
WTP Descriptor 39
|
|
WTP Fallback 40
|
|
WTP Frame Tunnel Mode 41
|
|
WTP IPv4 IP Address 42
|
|
WTP IPv6 IP Address 43
|
|
WTP MAC Type 44
|
|
WTP Name 45
|
|
WTP Operational Statistics 46
|
|
WTP Radio Statistics 47
|
|
WTP Reboot Statistics 48
|
|
WTP Static IP Address Information 49
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.1" href="#section-4.6.1">4.6.1</a>. AC Descriptor</span>
|
|
|
|
The AC Descriptor message element is used by the AC to communicate
|
|
its current state. The value contains the following fields.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 52]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-53" id="page-53" href="#page-53" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Stations | Limit |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Active WTPs | Max WTPs |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Security | R-MAC Field | Reserved1 | DTLS Policy |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=4 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=5 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 1 for AC Descriptor
|
|
|
|
Length: >= 12
|
|
|
|
Stations: The number of stations currently served by the AC
|
|
|
|
Limit: The maximum number of stations supported by the AC
|
|
|
|
Active WTPs: The number of WTPs currently attached to the AC
|
|
|
|
Max WTPs: The maximum number of WTPs supported by the AC
|
|
|
|
Security: A 8 bit bit mask specifying the authentication credential
|
|
type supported by the AC. The following values are supported (see
|
|
<a href="#section-2.4.4">Section 2.4.4</a>):
|
|
|
|
1 - X.509 Certificate Based
|
|
|
|
2 - Pre-Shared Secret
|
|
|
|
R-MAC Field: The AC supports the optional Radio MAC Address field
|
|
in the CAPWAP transport Header (see <a href="#section-4.3">Section 4.3</a>).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 53]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-54" id="page-54" href="#page-54" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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.
|
|
|
|
DTLS Policy: The AC communicates its policy on the use of DTLS for
|
|
the CAPWAP data channel. The AC MAY communicate more than one
|
|
supported option, represented by the bit field below. The WTP
|
|
MUST abide by one of the options communicated by AC. The
|
|
following bit field values are supported:
|
|
|
|
1 - Clear Text Data Channel Supported
|
|
|
|
2 - DTLS Enabled Data Channel Supported
|
|
|
|
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
|
|
Network Management Private Enterprise Codes"
|
|
|
|
Type: Vendor specific encoding of AC information. The following
|
|
values are supported. The Hardware and Software Version values
|
|
MUST be included.
|
|
|
|
4 - Hardware Version: The AC's hardware version number.
|
|
|
|
5 - Software Version: The AC's Software (firmware) version
|
|
number.
|
|
|
|
Length: Length of vendor specific encoding of AC information.
|
|
|
|
Value: Vendor specific encoding of AC information.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.2" href="#section-4.6.2">4.6.2</a>. AC IPv4 List</span>
|
|
|
|
The AC IPv4 List message element is used to configure a WTP with the
|
|
latest list of ACs available for the WTP to join.
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| AC IP Address[] |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 54]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-55" id="page-55" href="#page-55" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 2 for AC IPv4 List
|
|
|
|
Length: >= 4
|
|
|
|
The AC IP Address: An array of 32-bit integers containing AC IPv4
|
|
Addresses.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.3" href="#section-4.6.3">4.6.3</a>. AC IPv6 List</span>
|
|
|
|
The AC IPv6 List message element is used to configure a WTP with the
|
|
latest list of ACs available for the WTP to join.
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| AC IP Address[] |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| AC IP Address[] |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| AC IP Address[] |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| AC IP Address[] |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 3 for AC IPV6 List
|
|
|
|
Length: >= 16
|
|
|
|
The AC IP Address: An array of 128-bit integers containing AC IPv6
|
|
Addresses.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.4" href="#section-4.6.4">4.6.4</a>. AC Name</span>
|
|
|
|
The AC Name message element contains an UTF-8 representation of the
|
|
AC identity. The value is a variable length byte string. The string
|
|
is NOT zero terminated.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| Name ...
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 55]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-56" id="page-56" href="#page-56" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 4 for AC Name
|
|
|
|
Length: > 0
|
|
|
|
Name: A variable length UTF-8 encoded string containing the AC's
|
|
name
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.5" href="#section-4.6.5">4.6.5</a>. AC Name with Index</span>
|
|
|
|
The AC Name with Index message element is sent by the AC to the WTP
|
|
to configure preferred ACs. The number of instances of this message
|
|
element is equal to the number of ACs configured on the WTP.
|
|
|
|
0 1
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Index | AC Name...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 5 for AC Name with Index
|
|
|
|
Length: > 2
|
|
|
|
Index: The index of the preferred server (1=primary, 2=secondary).
|
|
|
|
AC Name: A variable length UTF-8 encoded string containing the AC
|
|
name.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.6" href="#section-4.6.6">4.6.6</a>. AC Timestamp</span>
|
|
|
|
The AC Timestamp message element is sent by the AC to synchronize the
|
|
WTP clock.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 6 for AC Timestamp
|
|
|
|
Length: 4
|
|
|
|
Timestamp: The AC's current time, allowing all of the WTPs to be
|
|
time synchronized in the format defined by Network Time Protocol
|
|
(NTP) in <a href="./rfc1305">RFC 1305</a> [<a href="#ref-3" title=""Network Time Protocol (Version 3) Specification, Implementation"">3</a>].
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 56]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-57" id="page-57" href="#page-57" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.7" href="#section-4.6.7">4.6.7</a>. Add MAC ACL Entry</span>
|
|
|
|
The Add MAC Access Control List (ACL) Entry message element is used
|
|
by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP
|
|
no longer provides service to the MAC addresses provided in the
|
|
message. The MAC Addresses provided in this message element are not
|
|
expected to be saved in non-volatile memory on the WTP.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Num of Entries| Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 7 for Add MAC ACL Entry
|
|
|
|
Length: >= 8
|
|
|
|
Num of Entries: The number of instances of the Type/MAC Addresses
|
|
fields in the array.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: MAC Addresses to add to the ACL.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.8" href="#section-4.6.8">4.6.8</a>. Add Station</span>
|
|
|
|
The Add Station message element is used by the AC to inform a WTP
|
|
that it should forward traffic for a station. The Add Station
|
|
message element is accompanied by technology specific binding
|
|
information element(s) which may include security parameters.
|
|
Consequently, the security parameters MUST be applied by the WTP for
|
|
the station.
|
|
|
|
After station policy has been delivered to the WTP through the Add
|
|
Station message element, an AC MAY change any policies by sending a
|
|
modified Add Station message element. When a WTP receives an Add
|
|
Station message element for an existing station, it MUST override any
|
|
existing state for the station.
|
|
|
|
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 | Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| VLAN Name...
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 57]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-58" id="page-58" href="#page-58" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 8 for Add Station
|
|
|
|
Length: >= 8
|
|
|
|
Radio ID: An 8-bit value representing the radio
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: The station's MAC Address
|
|
|
|
VLAN Name: An optional variable length UTF-8 encoded string
|
|
containing the VLAN Name on which the WTP is to locally bridge
|
|
user data. Note this field is only valid with WTPs configured in
|
|
Local MAC mode.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.9" href="#section-4.6.9">4.6.9</a>. Add Static MAC ACL Entry</span>
|
|
|
|
The Add Static MAC ACL Entry message element is used by an AC to add
|
|
a permanent ACL entry on a WTP, ensuring that the WTP no longer
|
|
provides any service to the MAC addresses provided in the message.
|
|
The MAC Addresses provided in this message element are expected to be
|
|
saved in non-volative memory on the WTP.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Num of Entries| Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 9 for Add Static MAC ACL Entry
|
|
|
|
Length: >= 8
|
|
|
|
Num of Entries: The number of instances of the Type/MAC Addresses
|
|
fields in the array.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: MAC Addresses to add to the permanent ACL.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.10" href="#section-4.6.10">4.6.10</a>. CAPWAP Control IPv4 Address</span>
|
|
|
|
The CAPWAP Control IPv4 Address message element is sent by the AC to
|
|
the WTP during the discovery process and is used by the AC to provide
|
|
the interfaces available on the AC, and the current number of WTPs
|
|
connected. When multiple CAPWAP Control IPV4 Address message
|
|
elements are returned, the WTP SHOULD perform load balancing across
|
|
the multiple interfaces.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 58]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-59" id="page-59" href="#page-59" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 10 for CAPWAP Control IPv4 Address
|
|
|
|
Length: 6
|
|
|
|
IP Address: The IP Address of an interface.
|
|
|
|
WTP Count: The number of WTPs currently connected to the interface.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.11" href="#section-4.6.11">4.6.11</a>. CAPWAP Control IPv6 Address</span>
|
|
|
|
The CAPWAP Control IPv6 Address message element is sent by the AC to
|
|
the WTP during the discovery process and is used by the AC to provide
|
|
the interfaces available on the AC, and the current number of WTPs
|
|
connected. This message element is useful for the WTP to perform
|
|
load balancing across multiple interfaces.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 11 for CAPWAP Control IPv6 Address
|
|
|
|
Length: 18
|
|
|
|
IP Address: The IP Address of an interface.
|
|
|
|
WTP Count: The number of WTPs currently connected to the interface.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 59]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-60" id="page-60" href="#page-60" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.12" href="#section-4.6.12">4.6.12</a>. CAPWAP Timers</span>
|
|
|
|
The CAPWAP Timers message element is used by an AC to configure
|
|
CAPWAP timers on a WTP.
|
|
|
|
0 1
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Discovery | Echo Request |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 12 for CAPWAP Timers
|
|
|
|
Length: 2
|
|
|
|
Discovery: The number of seconds between CAPWAP Discovery messages,
|
|
when the WTP is in the discovery phase.
|
|
|
|
Echo Request: The number of seconds between WTP Echo Request CAPWAP
|
|
messages. The default value for this message element is specified
|
|
in <a href="#section-4.7.5">Section 4.7.5</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.13" href="#section-4.6.13">4.6.13</a>. Data Transfer Data</span>
|
|
|
|
The Data Transfer Data message element is used by the WTP to provide
|
|
information to the AC for debugging purposes.
|
|
|
|
0 1 2
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Data Type | Data Length | Data ....
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 13 for Data Transfer Data
|
|
|
|
Length: >= 3
|
|
|
|
Data Type: An 8-bit value the type of information being sent. The
|
|
following values are supported:
|
|
|
|
1 - WTP Crash Data
|
|
|
|
2 - WTP Memory Dump
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 60]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-61" id="page-61" href="#page-61" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Data Length: Length of data field.
|
|
|
|
Data: Debug information.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.14" href="#section-4.6.14">4.6.14</a>. Data Transfer Mode</span>
|
|
|
|
The Data Transfer Mode message element is used by the WTP to indicate
|
|
the type of data transfer information it is sending to the AC for
|
|
debugging purposes.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| Data Type |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 14 for Data Transfer Mode
|
|
|
|
Length: 1
|
|
|
|
Data Type: An 8-bit value the type of information being requested.
|
|
The following values are supported:
|
|
|
|
1 - WTP Crash Data
|
|
|
|
2 - WTP Memory Dump
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.15" href="#section-4.6.15">4.6.15</a>. Decryption Error Report</span>
|
|
|
|
The Decryption Error Report message element value is used by the WTP
|
|
to inform the AC of decryption errors that have occurred since the
|
|
last report. Note that this error reporting mechanism is not used if
|
|
encryption and decryption services are provided in the AC.
|
|
|
|
0 1 2
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Radio ID |Num Of Entries | Length |MAC Address...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 15 for Decryption Error Report
|
|
|
|
Length: >= 9
|
|
|
|
Radio ID: The Radio Identifier refers to an interface index on the
|
|
WTP.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 61]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-62" id="page-62" href="#page-62" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Num of Entries: The number of instances of the Type/MAC Addresses
|
|
fields in the array.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: MAC addresses of the station that has caused
|
|
decryption errors.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.16" href="#section-4.6.16">4.6.16</a>. Decryption Error Report Period</span>
|
|
|
|
The Decryption Error Report Period message element value is used by
|
|
the AC to inform the WTP how frequently it should send decryption
|
|
error report messages. Note that this error reporting mechanism is
|
|
not used if encryption and decryption services are provided in the
|
|
AC.
|
|
|
|
0 1 2
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Radio ID | Report Interval |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 16 for Decryption Error Report Period
|
|
|
|
Length: 3
|
|
|
|
Radio ID: The Radio Identifier refers to an interface index on the
|
|
WTP.
|
|
|
|
Report Interval: A 16-bit unsigned integer indicating the time, in
|
|
seconds. The default value for this message element can be found
|
|
in <a href="#section-4.8.8">Section 4.8.8</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.17" href="#section-4.6.17">4.6.17</a>. Delete MAC ACL Entry</span>
|
|
|
|
The Delete MAC ACL Entry message element is used by an AC to delete a
|
|
MAC ACL entry on a WTP, ensuring that the WTP provides service to the
|
|
MAC addresses provided in the message.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Num of Entries| Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 62]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-63" id="page-63" href="#page-63" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 17 for Delete MAC ACL Entry
|
|
|
|
Length: >= 8
|
|
|
|
Num of Entries: The number of instances of the Type/MAC Addresses
|
|
fields in the array.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: An array of MAC Addresses to delete from the ACL.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.18" href="#section-4.6.18">4.6.18</a>. Delete Station</span>
|
|
|
|
The Delete Station message element is used by the AC to inform a WTP
|
|
that it should no longer provide service to a particular station.
|
|
The WTP MUST terminate service to the station immediately upon
|
|
receiving this message element.
|
|
|
|
The transmission of a Delete Station message element could occur for
|
|
various reasons, including for administrative reasons, or if the
|
|
station has roamed to another WTP.
|
|
|
|
The Delete Station message element MAY be sent by the WTP, in the WTP
|
|
Event Request message, to inform the AC that a particular station is
|
|
no longer being provided service. This could occur as a result of an
|
|
Idle Timeout (see <a href="#section-4.4.43">section 4.4.43</a>), due to internal resource shortages
|
|
or for some other reason.
|
|
|
|
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 | Length | MAC Address...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 18 for Delete Station
|
|
|
|
Length: >= 8
|
|
|
|
Radio ID: An 8-bit value representing the radio
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: The station's MAC Address
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 63]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-64" id="page-64" href="#page-64" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.19" href="#section-4.6.19">4.6.19</a>. Delete Static MAC ACL Entry</span>
|
|
|
|
The Delete Static MAC ACL Entry message element is used by an AC to
|
|
delete a previously added static MAC ACL entry on a WTP, ensuring
|
|
that the WTP provides service to the MAC addresses provided in the
|
|
message.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Num of Entries| Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 19 for Delete Static MAC ACL Entry
|
|
|
|
Length: >= 8
|
|
|
|
Num of Entries: The number of instances of the Type/MAC Addresses
|
|
fields in the array.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: An array of MAC Addresses to delete from the static
|
|
MAC ACL entry.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.20" href="#section-4.6.20">4.6.20</a>. Discovery Type</span>
|
|
|
|
The Discovery Type message element is used by the WTP to indicate how
|
|
it has come to know about the existence of the AC to which it is
|
|
sending the Discovery Request message.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| Discovery Type|
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 20 for Discovery Type
|
|
|
|
Length: 1
|
|
|
|
Discovery Type: An 8-bit value indicating how the WTP discovered
|
|
the AC. The following values are supported:
|
|
|
|
0 - Unknown
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 64]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-65" id="page-65" href="#page-65" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
1 - Static Configuration
|
|
|
|
2 - DHCP
|
|
|
|
3 - DNS
|
|
|
|
4 - AC Referral (used when the AC was configured either through
|
|
the AC IPv4 List or AC IPv6 List message element)
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.21" href="#section-4.6.21">4.6.21</a>. Duplicate IPv4 Address</span>
|
|
|
|
The Duplicate IPv4 Address message element is used by a WTP to inform
|
|
an AC that it has detected another IP device using the same IP
|
|
address that the WTP is currently using.
|
|
|
|
The WTP MUST transmit this message element with the status set to 1
|
|
after it has detected a duplicate IP address. When the WTP detects
|
|
that the duplicate IP address has been cleared, it MUSY send this
|
|
message element with the status set to 0.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Status | Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 21 for Duplicate IPv4 Address
|
|
|
|
Length: >= 12
|
|
|
|
IP Address: The IP Address currently used by the WTP.
|
|
|
|
Status: The status of the duplicate IP address. The value MUST be
|
|
set to 1 when a duplicate address is detected, and 0 when the
|
|
duplicate address has been cleared.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: The MAC Address of the offending device.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.22" href="#section-4.6.22">4.6.22</a>. Duplicate IPv6 Address</span>
|
|
|
|
The Duplicate IPv6 Address message element is used by a WTP to inform
|
|
an AC that it has detected another host using the same IP address
|
|
that the WTP is currently using.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 65]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-66" id="page-66" href="#page-66" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
The WTP MUST transmit this message element with the status set to 1
|
|
after it has detected a duplicate IP address. When the WTP detects
|
|
that the duplicate IP address has been cleared, it MUST send this
|
|
message element with the status set to 0.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Status | Length | MAC Address ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 23 for Duplicate IPv6 Address
|
|
|
|
Length: >= 24
|
|
|
|
IP Address: The IP Address currently used by the WTP.
|
|
|
|
Status: The status of the duplicate IP address. The value MUST be
|
|
set to 1 when a duplicate address is detected, and 0 when the
|
|
duplicate address has been cleared.
|
|
|
|
Length: The length of the MAC Address field.
|
|
|
|
MAC Address: The MAC Address of the offending device.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.23" href="#section-4.6.23">4.6.23</a>. Idle Timeout</span>
|
|
|
|
The Idle Timeout message element is sent by the AC to the WTP to
|
|
provide the idle timeout value that the WTP SHOULD enforce for its
|
|
active stations. The value applies to all radios on the WTP.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timeout |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 66]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-67" id="page-67" href="#page-67" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 23 for Idle Timeout
|
|
|
|
Length: 4
|
|
|
|
Timeout: The current idle timeout to be enforced by the WTP. The
|
|
default value for this message element is specified in
|
|
<a href="#section-4.8.5">Section 4.8.5</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.24" href="#section-4.6.24">4.6.24</a>. Image Data</span>
|
|
|
|
The Image Data message element is present in the Image Data Request
|
|
message sent by the AC and contains the following fields.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Opcode | Value ...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 24 for Image Data
|
|
|
|
Length: >= 1
|
|
|
|
Opcode: An 8-bit value representing the transfer opcode. The
|
|
following values are supported:
|
|
|
|
1 - Image data is included
|
|
|
|
2 - Last Image Data Block is included (EOF)
|
|
|
|
5 - An error occurred. Transfer is aborted
|
|
|
|
Value: The Image Data field contains up to 1024 characters. If the
|
|
block being sent is the last one, the Opcode is set to 2. The AC
|
|
MAY opt to abort the data transfer by setting the Opcode to 5.
|
|
When the Opcode is 5, the Value field has a zero length.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.25" href="#section-4.6.25">4.6.25</a>. Image Identifier</span>
|
|
|
|
The Image Identifier message element is sent by the AC to the WTP and
|
|
is used to indicate the expected active software version that is to
|
|
be run on the WTP. The value is a variable length UTF-8 encoded
|
|
string, which is NOT zero terminated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 67]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-68" id="page-68" href="#page-68" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 25 for Image Identifier
|
|
|
|
Length: >= 1
|
|
|
|
Value: A variable length UTF-8 encoded string containing the
|
|
firmware identifier to be run on the WTP.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.26" href="#section-4.6.26">4.6.26</a>. Image Information</span>
|
|
|
|
The Image Information message element is present in the Image Data
|
|
Response message sent by the AC to the WTP and contains the following
|
|
fields.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| File Size | Hash |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Hash |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Hash |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Hash |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Hash |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 26 for Image Information
|
|
|
|
Length: 18
|
|
|
|
File Size: A 16-bit value containing the size of the file that will
|
|
be transfered by the AC to the WTP.
|
|
|
|
Hash: A 16 octet hash of the image. The hash is computed using
|
|
MD5, using the following pseudo-code:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 68]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-69" id="page-69" href="#page-69" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
#include <md5.h>
|
|
CapwapCreateHash(char *hash, char *image, int image_len)
|
|
{
|
|
MD_CTX context;
|
|
|
|
MDInit (&context);
|
|
MDUpdate (&context, buffer, len);
|
|
MDFinal (hash, &context);
|
|
}
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.27" href="#section-4.6.27">4.6.27</a>. Initiate Download</span>
|
|
|
|
The Initiate Download message element is used by the AC to inform the
|
|
WTP that the WTP SHOULD initiate a firmware upgrade. The WTP
|
|
subsequently transmits an Image Data Request message which includes
|
|
the Image Download message element. This message element does not
|
|
contain any data.
|
|
|
|
Type: 27 for Initiate Download
|
|
|
|
Length: 0
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.28" href="#section-4.6.28">4.6.28</a>. Location Data</span>
|
|
|
|
The Location Data message element is a variable length byte UTF-8
|
|
encoded string containing user defined location information (e.g.
|
|
"Next to Fridge"). This information is configurable by the network
|
|
administrator, and allows the WTP location to be determined. The
|
|
string is not zero terminated.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+-
|
|
| Location ...
|
|
+-+-+-+-+-+-+-+-+-
|
|
|
|
Type: 28 for Location Data
|
|
|
|
Length: > 0
|
|
|
|
Location: A non-zero terminated UTF-8 encoded string containing the
|
|
WTP location.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.29" href="#section-4.6.29">4.6.29</a>. Maximum Message Length</span>
|
|
|
|
The Maximum Message Length message element is included in the Join
|
|
Request message by the WTP to indicate the maximum CAPWAP message
|
|
length that it supports to the AC. The Maximum Message Length
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 69]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-70" id="page-70" href="#page-70" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
message element is optionally included in Join Response message by
|
|
the AC to indicate the maximum CAPWAP message length that it supports
|
|
to the WTP.
|
|
|
|
0 1 2
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|
|
| Maximum Message Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|
|
|
|
|
|
Type: 29 for Maximim Message Length
|
|
|
|
Length: 2
|
|
|
|
Maximum Message Length An 16-bit unsigned integer indicating the
|
|
maximum message length.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.30" href="#section-4.6.30">4.6.30</a>. MTU Discovery Padding</span>
|
|
|
|
The MTU Discovery Padding message element is used as padding to
|
|
perform MTU discovery, and MUST contain octets of value 0xFF, of any
|
|
length
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| Padding...
|
|
+-+-+-+-+-+-+-+-
|
|
|
|
|
|
Type: 30 for MTU Discovery Padding
|
|
|
|
Length: variable
|
|
|
|
Pad: A variable length pad.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.31" href="#section-4.6.31">4.6.31</a>. Radio Administrative State</span>
|
|
|
|
The Radio Administrative State message element is used to communicate
|
|
the state of a particular radio. The Radio Administrative State
|
|
message element is sent by the AC to change the state of the WTP.
|
|
The WTP saves the value, to ensure that it remains across WTP resets.
|
|
The WTP communicates this message element during the configuration
|
|
phase, in the Configuration Status Request message, to ensure that AC
|
|
has the WTP radio current administrative state settings. The message
|
|
element contains the following fields.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 70]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-71" id="page-71" href="#page-71" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
0 1
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Radio ID | Admin State |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 31 for Radio Administrative State
|
|
|
|
Length: 2
|
|
|
|
Radio ID: An 8-bit value representing the radio to configure. The
|
|
Radio ID field MAY also include the value of 0xff, which is used
|
|
to identify the WTP. If an AC wishes to change the administrative
|
|
state of a WTP, it includes 0xff in the Radio ID field.
|
|
|
|
Admin State: An 8-bit value representing the administrative state
|
|
of the radio. The default value for the Admin State field is
|
|
listed in <a href="#section-4.8.1">Section 4.8.1</a>. The following values are supported:
|
|
|
|
1 - Enabled
|
|
|
|
2 - Disabled
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.32" href="#section-4.6.32">4.6.32</a>. Radio Operational State</span>
|
|
|
|
The Radio Operational State message element is sent by the WTP to the
|
|
AC to communicate a radio's operational state. This message element
|
|
is included in the Configuration Update Response message by the WTP
|
|
if it was requested to change the state of its radio, via the Radio
|
|
Administrative State message element, but was unable to comply to the
|
|
request. This message element is included in the Change State Event
|
|
message when a WTP radio state was changed unexpectedly. This could
|
|
occur due to a hardware failure. Note that the operational state
|
|
setting is not saved on the WTP, and therefore does not remain across
|
|
WTP resets. The value contains three fields, as shown below.
|
|
|
|
0 1 2
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Radio ID | State | Cause |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 32 for Radio Operational State
|
|
|
|
Length: 3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 71]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-72" id="page-72" href="#page-72" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Radio ID: The Radio Identifier refers to an interface index on the
|
|
WTP. A value of 0xFF is invalid, as it is not possible to change
|
|
the WTP's operational state.
|
|
|
|
State: An 8-bit boolean value representing the state of the radio.
|
|
A value of one disables the radio, while a value of two enables
|
|
it.
|
|
|
|
Cause: When a radio is inoperable, the cause field contains the
|
|
reason the radio is out of service. The following values are
|
|
supported:
|
|
|
|
0 - Normal
|
|
|
|
1 - Radio Failure
|
|
|
|
2 - Software Failure
|
|
|
|
3 - Administratively Set
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.33" href="#section-4.6.33">4.6.33</a>. Result Code</span>
|
|
|
|
The Result Code message element value is a 32-bit integer value,
|
|
indicating the result of the Request message corresponding to the
|
|
Sequence Number included in the Response message.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Result Code |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 33 for Result Code
|
|
|
|
Length: 4
|
|
|
|
Result Code: The following values are defined:
|
|
|
|
0 Success
|
|
|
|
1 Failure (AC List message element MUST be present)
|
|
|
|
2 Success (NAT detected)
|
|
|
|
3 Join Failure (unspecified)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 72]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-73" id="page-73" href="#page-73" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
4 Join Failure (Resource Depletion)
|
|
|
|
5 Join Failure (Unknown Source)
|
|
|
|
6 Join Failure (Incorrect Data)
|
|
|
|
7 Join Failure (Session ID already in use)
|
|
|
|
8 Join Failure (WTP Hardware not supported)
|
|
|
|
9 Join Failure (Binding Not Supported)
|
|
|
|
10 Reset Failure (Unable to Reset)
|
|
|
|
11 Reset Failure (Firmware Write Error)
|
|
|
|
12 Configuration Failure (Unable to Apply Requested Configuration
|
|
- Service Provided Anyhow)
|
|
|
|
13 Configuration Failure (Unable to Apply Requested Configuration
|
|
- Service Not Provided)
|
|
|
|
14 Image Data Error (Invalid Checksum)
|
|
|
|
15 Image Data Error (Invalid Data Length)
|
|
|
|
16 Image Data Error (Other Error)
|
|
|
|
17 Image Data Error (Image Already Present)
|
|
|
|
18 Message Unexpected (Invalid in current state)
|
|
|
|
19 Message Unexpected (Unrecognized Request)
|
|
|
|
20 Failure - Missing Mandatory Message Element
|
|
|
|
21 Failure - Unrecognized Message Element
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.34" href="#section-4.6.34">4.6.34</a>. Returned Message Element</span>
|
|
|
|
The Returned Message Element is sent by the WTP in the Change State
|
|
Event Request message to communicate to the AC which message elements
|
|
in the Configuration Status Response it was unable to apply locally.
|
|
The Returned Message Element message element contains a result code
|
|
indicating the reason that the configuration could not be applied,
|
|
and encapsulates the failed message element.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 73]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-74" id="page-74" href="#page-74" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
0 1 2
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reason | Message Element...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 34 for Returned Message Element
|
|
|
|
Length: >= 1
|
|
|
|
Reason: The reason why the configuration in the offending message
|
|
element could not be applied by the WTP.
|
|
|
|
1 - Unknown Message Element
|
|
|
|
2 - Unsupported Message Element
|
|
|
|
3 - Unknown Message Element Value
|
|
|
|
4 - Unsupported Message Element Value
|
|
|
|
Message Element: The Message Element field encapsulates the message
|
|
element sent by the AC in the Configuration Status Response
|
|
message that caused the error.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.35" href="#section-4.6.35">4.6.35</a>. Session ID</span>
|
|
|
|
The Session ID message element value contains a randomly generated
|
|
unsigned 32-bit integer.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Session ID |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 35 for Session ID
|
|
|
|
Length: 16
|
|
|
|
Session ID: A 32-bit unsigned integer used as a random session
|
|
identifier
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 74]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-75" id="page-75" href="#page-75" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.36" href="#section-4.6.36">4.6.36</a>. Statistics Timer</span>
|
|
|
|
The Statistics Timer message element value is used by the AC to
|
|
inform the WTP of the frequency with which it expects to receive
|
|
updated statistics.
|
|
|
|
0 1
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Statistics Timer |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 36 for Statistics Timer
|
|
|
|
Length: 2
|
|
|
|
Statistics Timer: A 16-bit unsigned integer indicating the time, in
|
|
seconds. The default value for this timer is specified in
|
|
<a href="#section-4.7.12">Section 4.7.12</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.37" href="#section-4.6.37">4.6.37</a>. Vendor Specific Payload</span>
|
|
|
|
The Vendor Specific Payload message element is used to communicate
|
|
vendor specific information between the WTP and the AC. The message
|
|
element uses the following format:
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Element ID | Value... |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 37 for Vendor Specific
|
|
|
|
Length: >= 7
|
|
|
|
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
|
|
Network Management Private Enterprise Codes" [<a href="#ref-14" title=""Assigned Numbers: RFC 1700 is Replaced by an On- line Database"">14</a>]
|
|
|
|
Element ID: A 16-bit Element Identifier which is managed by the
|
|
vendor.
|
|
|
|
Value: The value associated with the vendor specific element.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 75]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-76" id="page-76" href="#page-76" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.38" href="#section-4.6.38">4.6.38</a>. WTP Board Data</span>
|
|
|
|
The WTP Board Data message element is sent by the WTP to the AC and
|
|
contains information about the hardware present.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=0 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=1 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Optional additional vendor specific WTP board data TLVs.....
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 38 for WTP Board Data
|
|
|
|
Length: >=14
|
|
|
|
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
|
|
Network Management Private Enterprise Codes"
|
|
|
|
Type: The following values are supported:
|
|
|
|
0 - WTP Model Number: The WTP Model Number MUST be included in
|
|
the WTP Board Data message element.
|
|
|
|
1 - WTP Serial Number: The WTP Serial Number MUST be included in
|
|
the WTP Board Data message element.
|
|
|
|
2 - Board ID: A hardware identifier, which MAY be included in
|
|
the WTP Board Data mesage element.
|
|
|
|
3 - Board Revision A revision number of the board, which MAY be
|
|
included in the WTP Board Data message element.
|
|
|
|
4 - Base MAC Addres The WTP's Base MAC Address, which MAY be
|
|
assigned to the primary Ethernet interface.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 76]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-77" id="page-77" href="#page-77" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.39" href="#section-4.6.39">4.6.39</a>. WTP Descriptor</span>
|
|
|
|
The WTP Descriptor message element is used by a WTP to communicate
|
|
its current hardware and software (firmware) configuration. The
|
|
value contains the following fields.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Max Radios | Radios in use | Encryption Capabilities |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=0 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=1 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=2 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Vendor Identifier |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type=3 | Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 39 for WTP Descriptor
|
|
|
|
Length: >= 31
|
|
|
|
Max Radios: An 8-bit value representing the number of radios (where
|
|
each radio is identified via the Radio ID field) supported by the
|
|
WTP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 77]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-78" id="page-78" href="#page-78" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Radios in use: An 8-bit value representing the number of radios in
|
|
use in the WTP.
|
|
|
|
Encryption Capabilities: This 16-bit field is used by the WTP to
|
|
communicate its capabilities to the AC. A WTP that does not have
|
|
any encryption capabilities sets this field to zero (0). Refer to
|
|
the specific wireless binding for further specification of the
|
|
Encryption Capabilities field.
|
|
|
|
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
|
|
Network Management Private Enterprise Codes".
|
|
|
|
Type: The following values are supported. The Hardware Version,
|
|
Active Software Version, and Boot Version values MUST be included.
|
|
Zero or more Other Software Version values MAY be included.
|
|
|
|
0 - Hardware Version: The WTP hardware version number.
|
|
|
|
1 - Active Software Version: The WTP running software version
|
|
number.
|
|
|
|
2 - Boot Version: The WTP boot loader version number.
|
|
|
|
3 - Other Software Version: The WTP non-running software
|
|
(firmware) version number.
|
|
|
|
Length: Length of vendor specific encoding of WTP information.
|
|
|
|
Value: Vendor specific data of WTP information encoded in the UTF-8
|
|
format.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.40" href="#section-4.6.40">4.6.40</a>. WTP Fallback</span>
|
|
|
|
The WTP Fallback message element is sent by the AC to the WTP to
|
|
enable or disable automatic CAPWAP fallback in the event that a WTP
|
|
detects its preferred AC, and is not currently connected to it.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| Mode |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 40 for WTP Fallback
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 78]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-79" id="page-79" href="#page-79" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Length: 1
|
|
|
|
Mode: The 8-bit value indicates the status of automatic CAPWAP
|
|
fallback on the WTP. When enabled, if the WTP detects that its
|
|
primary AC is available, and that the WTP is not connected to the
|
|
primary AC, the WTP SHOULD automatically disconnect from its
|
|
current AC and reconnect to its primary AC. If disabled, the WTP
|
|
will only reconnect to its primary AC through manual intervention
|
|
(e.g., through the Reset Request message). The default value for
|
|
this field is specified in <a href="#section-4.8.10">Section 4.8.10</a>. The following values
|
|
are supported:
|
|
|
|
1 - Enabled
|
|
|
|
2 - Disabled
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.41" href="#section-4.6.41">4.6.41</a>. WTP Frame Tunnel Mode</span>
|
|
|
|
The WTP Frame Tunnel Mode message element allows the WTP to
|
|
communicate the tunneling modes of operation which it supports to the
|
|
AC. A WTP that advertises support for all types allows the AC to
|
|
select which type will be used, based on its local policy.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| Tunnel Mode |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 41 for WTP Frame Tunnel Mode
|
|
|
|
Length: 1
|
|
|
|
Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling
|
|
modes for station data that are supported by the WTP. The
|
|
following values are supported:
|
|
|
|
1 - Local Bridging: When Local Bridging is used, the WTP does
|
|
not tunnel user traffic to the AC; all user traffic is locally
|
|
bridged. This value MUST NOT be used when the WTP MAC Type is
|
|
set to Split-MAC.
|
|
|
|
2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode
|
|
requires the WTP and AC to encapsulate all user payload as
|
|
native IEEE 802.3 frames (see <a href="#section-4.4">Section 4.4</a>). All user traffic
|
|
is tunneled to the AC. This value MUST NOT be used when the
|
|
WTP MAC Type is set to Split-MAC.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 79]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-80" id="page-80" href="#page-80" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires
|
|
the WTP and AC to encapsulate all user payloads as native
|
|
wireless frames, as defined by the wireless binding (see for
|
|
example <a href="#section-4.4">Section 4.4</a>).
|
|
|
|
7 - All: The WTP is capable of supporting all frame tunnel
|
|
modes.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.42" href="#section-4.6.42">4.6.42</a>. WTP IPv4 IP Address</span>
|
|
|
|
The WTP IPv4 address is used to perform NAT detection.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP IPv4 IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 42 for WTP IPv4 IP Address
|
|
|
|
Length: 4
|
|
|
|
WTP IPv4 IP Address: The IPv4 address from which the WTP is sending
|
|
packets. This field is used for NAT detection.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.43" href="#section-4.6.43">4.6.43</a>. WTP IPv6 IP Address</span>
|
|
|
|
The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to
|
|
IPv6 NAT to help with technology transition).
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP IPv6 IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP IPv6 IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP IPv6 IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| WTP IPv6 IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 80]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-81" id="page-81" href="#page-81" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 43 for WTP IPv6 IP Address
|
|
|
|
Length: 32
|
|
|
|
WTP IPv6 IP Address: The IPv6 address from which the WTP is sending
|
|
packets. This field is used for NAT detection.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.44" href="#section-4.6.44">4.6.44</a>. WTP MAC Type</span>
|
|
|
|
The WTP MAC-Type message element allows the WTP to communicate its
|
|
mode of operation to the AC. A WTP that advertises support for both
|
|
modes allows the AC to select the mode to use, based on local policy.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+
|
|
| MAC Type |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 44 for WTP MAC Type
|
|
|
|
Length: 1
|
|
|
|
MAC Type: The MAC mode of operation supported by the WTP. The
|
|
following values are supported
|
|
|
|
0 - Local-MAC: Local-MAC is the default mode that MUST be
|
|
supported by all WTPs.
|
|
|
|
1 - Split-MAC: Split-MAC support is optional, and allows the AC
|
|
to receive and process native wireless frames.
|
|
|
|
2 - Both: WTP is capable of supporting both Local-MAC and Split-
|
|
MAC.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.45" href="#section-4.6.45">4.6.45</a>. WTP Name</span>
|
|
|
|
The WTP Name message element is a variable length byte UTF-8 encoded
|
|
string. The string is not zero terminated.
|
|
|
|
0
|
|
0 1 2 3 4 5 6 7
|
|
+-+-+-+-+-+-+-+-+-
|
|
| WTP Name ...
|
|
+-+-+-+-+-+-+-+-+-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 81]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-82" id="page-82" href="#page-82" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Type: 45 for WTP Name
|
|
|
|
Length: variable
|
|
|
|
WTP Name: A non-zero terminated UTF-8 encoded string containing the
|
|
WTP name.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.46" href="#section-4.6.46">4.6.46</a>. WTP Operational Statistics</span>
|
|
|
|
The WTP Operational Statistics message element is sent by the WTP to
|
|
the AC to provide statistics related to the operation of the WTP.
|
|
|
|
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 | Tx Queue Level | Wireless Link Frames per Sec |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 46 for WTP Operational Statistics
|
|
|
|
Length: 4
|
|
|
|
Radio ID: The radio ID of the radio to which the statistics apply.
|
|
|
|
Wireless Transmit Queue Level: The percentage of Wireless Transmit
|
|
queue utilization, calculated as the sum of utilized transmit
|
|
queue lengths divided by the sum of maximum transmit queue
|
|
lengths, multiplied by 100. The Wireless Transmit Queue Level is
|
|
representative of congestion conditions over wireless interfaces
|
|
between the WTP and stations.
|
|
|
|
Wireless Link Frames per Sec: The number of frames transmitted or
|
|
received per second by the WTP over the air interface.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.47" href="#section-4.6.47">4.6.47</a>. WTP Radio Statistics</span>
|
|
|
|
The WTP Radio Statistics message element is sent by the WTP to the AC
|
|
to communicate statistics on radio behavior and reasons why the WTP
|
|
radio has been reset.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 82]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-83" id="page-83" href="#page-83" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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 | Last Fail Type| Reset Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| SW Failure Count | HW Failure Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Other Failure Count | Unknown Failure Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Config Update Count | Channel Change Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Band Change Count | Current Noise Floor |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 47 for WTP Radio Statistics
|
|
|
|
Length: 20
|
|
|
|
Radio ID: The radio ID of the radio to which the statistics apply.
|
|
|
|
Last Failure Type: The last WTP failure. The following values are
|
|
supported:
|
|
|
|
0 - Statistic Not Supported
|
|
|
|
1 - Software Failure
|
|
|
|
2 - Hardware Failure
|
|
|
|
3 - Other Failure
|
|
|
|
255 - Unknown (e.g., WTP doesn't keep track of info)
|
|
|
|
Reset Count: The number of times that that the radio has been
|
|
reset.
|
|
|
|
SW Failure Count: The number of times that the radio has failed due
|
|
to software related reasons.
|
|
|
|
HW Failure Count: The number of times that the radio has failed due
|
|
to hardware related reasons.
|
|
|
|
Other Failure Count: The number of times that the radio has failed
|
|
due to known reasons, other than software or hardware failure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 83]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-84" id="page-84" href="#page-84" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Unknown Failure Count: The number of times that the radio has
|
|
failed for unknown reasons.
|
|
|
|
Config Update Count: The number of times that the radio
|
|
configuration has been updated.
|
|
|
|
Channel Change Count: The number of times that the radio channel
|
|
has been changed.
|
|
|
|
Band Change Count: The number of times that the radio has changed
|
|
frequency bands.
|
|
|
|
Current Noise Floor: A signed integer which indicates the noise
|
|
floor of the radio receiver in units of dBm.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.48" href="#section-4.6.48">4.6.48</a>. WTP Reboot Statistics</span>
|
|
|
|
The WTP Reboot Statistics message element is sent by the WTP to the
|
|
AC to communicate reasons why WTP reboots have occurred.
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reboot Count | AC Initiated Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Link Failure Count | SW Failure Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| HW Failure Count | Other Failure Count |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Unknown Failure Count |Last Failure Type|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Type: 48 for WTP Reboot Statistics
|
|
|
|
Length: 15
|
|
|
|
Reboot Count: The number of reboots that have occurred due to a WTP
|
|
crash. A value of 65535 implies that this information is not
|
|
available on the WTP.
|
|
|
|
AC Initiated Count: The number of reboots that have occurred at the
|
|
request of a CAPWAP protocol message, such as a change in
|
|
configuration that required a reboot or an explicit CAPWAP
|
|
protocol reset request. A value of 65535 implies that this
|
|
information is not available on the WTP.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 84]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-85" id="page-85" href="#page-85" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Link Failure Count: The number of times that a CAPWAP protocol
|
|
connection with an AC has failed due to link failure.
|
|
|
|
SW Failure Count: The number of times that a CAPWAP protocol
|
|
connection with an AC has failed due to software related reasons.
|
|
|
|
HW Failure Count: The number of times that a CAPWAP protocol
|
|
connection with an AC has failed due to hardware related reasons.
|
|
|
|
Other Failure Count: The number of times that a CAPWAP protocol
|
|
connection with an AC has failed due to known reasons, other than
|
|
AC initiated, link, SW or HW failure.
|
|
|
|
Unknown Failure Count: The number of times that a CAPWAP protocol
|
|
connection with an AC has failed for unknown reasons.
|
|
|
|
Last Failure Type: The failure type of the most recent WTP failure.
|
|
The following values are supported:
|
|
|
|
0 - Not Supported
|
|
|
|
1 - AC Initiated (see <a href="#section-9.2">Section 9.2</a>)
|
|
|
|
2 - Link Failure
|
|
|
|
3 - Software Failure
|
|
|
|
4 - Hardware Failure
|
|
|
|
5 - Other Failure
|
|
|
|
255 - Unknown (e.g., WTP doesn't keep track of info)
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.6.49" href="#section-4.6.49">4.6.49</a>. WTP Static IP Address Information</span>
|
|
|
|
The WTP Static IP Address Information message element is used by an
|
|
AC to configure or clear a previously configured static IP address on
|
|
a WTP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 85]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-86" id="page-86" href="#page-86" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Address |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Netmask |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Gateway |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Static |
|
|
+-+-+-+-+-+-+-+-+
|
|
|
|
Type: 49 for WTP Static IP Address Information
|
|
|
|
Length: 13
|
|
|
|
IP Address: The IP Address to assign to the WTP. This field is
|
|
only valid if the static field is set to one.
|
|
|
|
Netmask: The IP Netmask. This field is only valid if the static
|
|
field is set to one.
|
|
|
|
Gateway: The IP address of the gateway. This field is only valid
|
|
if the static field is set to one.
|
|
|
|
Netmask: The IP Netmask. This field is only valid if the static
|
|
field is set to one.
|
|
|
|
Static: An 8-bit boolean stating whether the WTP should use a
|
|
static IP address or not. A value of zero disables the static IP
|
|
address, while a value of one enables it.
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.7" href="#section-4.7">4.7</a>. CAPWAP Protocol Timers</span>
|
|
|
|
This section contains the CAPWAP timers.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.1" href="#section-4.7.1">4.7.1</a>. ChangeStatePendingTimer</span>
|
|
|
|
The maximum time, in seconds, the AC will wait for the Change State
|
|
Event Request from the WTP after having transmitted a successful
|
|
Configuration Status Response message. The default value is 25
|
|
seconds.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.2" href="#section-4.7.2">4.7.2</a>. DataChannelDeadInterval</span>
|
|
|
|
The minimum time, in seconds, a WTP MUST wait without having received
|
|
a Data Channel Keep Alive packet before the destination for the Data
|
|
Channel Keep Alive packets may be considered dead. The value of this
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 86]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-87" id="page-87" href="#page-87" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
timer MUST be no less than 2*DataChannelKeepAlive seconds and no
|
|
greater that 240 seconds.
|
|
|
|
Default: 5
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.3" href="#section-4.7.3">4.7.3</a>. DiscoveryInterval</span>
|
|
|
|
The minimum time, in seconds, that a WTP MUST wait after receiving a
|
|
Discovery Response message, before initiating a DTLS handshake.
|
|
|
|
Default: 5
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.4" href="#section-4.7.4">4.7.4</a>. DTLSSessionDelete</span>
|
|
|
|
The minimum time, in seconds, a WTP MUST wait for DTLS session
|
|
deletion.
|
|
|
|
Default: 5
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.5" href="#section-4.7.5">4.7.5</a>. EchoInterval</span>
|
|
|
|
The minimum time, in seconds, between sending Echo Request messages
|
|
to the AC with which the WTP has joined.
|
|
|
|
Default: 30
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.6" href="#section-4.7.6">4.7.6</a>. MaxDiscoveryInterval</span>
|
|
|
|
The maximum time allowed between sending Discovery Request messages,
|
|
in seconds. This value MUST be no less than 2 seconds and no greater
|
|
than 180 seconds.
|
|
|
|
Default: 20 seconds.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.7" href="#section-4.7.7">4.7.7</a>. MaxFailedDTLSSessionRetry</span>
|
|
|
|
The maximum number of failed DTLS session establishment attempts
|
|
before the CAPWAP device enters a silent period.
|
|
|
|
Default: 3.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.8" href="#section-4.7.8">4.7.8</a>. NeighborDeadInterval</span>
|
|
|
|
The minimum time, in seconds, a WTP MUST wait without having received
|
|
an Echo Response message to its Echo Request message, before the
|
|
destination for the Echo Request may be considered dead. This value
|
|
MUST be no less than 2*EchoInterval seconds and no greater than 240
|
|
seconds.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 87]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-88" id="page-88" href="#page-88" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Default: 60
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.9" href="#section-4.7.9">4.7.9</a>. ResponseTimeout</span>
|
|
|
|
The minimum time, in seconds, in which the WTP or AC MUST respond to
|
|
a CAPWAP Request message.
|
|
|
|
Default: 1
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.10" href="#section-4.7.10">4.7.10</a>. RetransmitInterval</span>
|
|
|
|
The minimum time, in seconds, in which a non-acknowledged CAPWAP
|
|
packet will be retransmitted.
|
|
|
|
Default: 3
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.11" href="#section-4.7.11">4.7.11</a>. SilentInterval</span>
|
|
|
|
For a WTP, this is the minimum time, in seconds, a WTP MUST wait
|
|
before it MAY again send Discovery Request messages or attempt to a
|
|
establish DTLS session. For an AC, this is the minimum time, in
|
|
seconds, during which the AC SHOULD ignore all CAPWAP and DTLS
|
|
packets received from the WTP that is in the Sulking state.
|
|
|
|
Default: 30
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.12" href="#section-4.7.12">4.7.12</a>. StatisticsTimer</span>
|
|
|
|
The default Statistics Interval is 120 seconds.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.13" href="#section-4.7.13">4.7.13</a>. WaitDTLS</span>
|
|
|
|
The maximum time, in seconds, a WTP MUST wait without having received
|
|
a DTLS Handshake message from an AC. This timer MUST be greater than
|
|
30 seconds.
|
|
|
|
Default: 60
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.7.14" href="#section-4.7.14">4.7.14</a>. WaitJoin</span>
|
|
|
|
The maximum time, in seconds, after which the DTLS session has been
|
|
established that the AC will wait before receiving a Join Request
|
|
message. This timer MUST be greater than 30 seconds.
|
|
|
|
Default: 60
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 88]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-89" id="page-89" href="#page-89" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.8" href="#section-4.8">4.8</a>. CAPWAP Protocol Variables</span>
|
|
|
|
A WTP or AC that implements the CAPWAP Discovery phase MUST allow for
|
|
the following variables to be configured by system management;
|
|
default values are specified, making explicit configuration
|
|
unnecessary in many cases. If the default values are explicitly
|
|
overriden by the AC, the WTP MUST save the values sent by the AC.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.1" href="#section-4.8.1">4.8.1</a>. AdminState</span>
|
|
|
|
The default Administrative State value is enabled (1).
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.2" href="#section-4.8.2">4.8.2</a>. DiscoveryCount</span>
|
|
|
|
The number of Discovery Request messages transmitted by a WTP to a
|
|
single AC. This is a monotonically increasing counter.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.3" href="#section-4.8.3">4.8.3</a>. FailedDTLSAuthFailCount</span>
|
|
|
|
The number of failed DTLS session establishment attempts due to
|
|
authentication failures.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.4" href="#section-4.8.4">4.8.4</a>. FailedDTLSSessionCount</span>
|
|
|
|
The number of failed DTLS session establishment attempts.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.5" href="#section-4.8.5">4.8.5</a>. IdleTimeout</span>
|
|
|
|
The default Idle Timeout is 300 seconds.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.6" href="#section-4.8.6">4.8.6</a>. MaxDiscoveries</span>
|
|
|
|
The maximum number of Discovery Request messages that will be sent
|
|
after a WTP boots.
|
|
|
|
Default: 10
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.7" href="#section-4.8.7">4.8.7</a>. MaxRetransmit</span>
|
|
|
|
The maximum number of retransmissions for a given CAPWAP packet
|
|
before the link layer considers the peer dead.
|
|
|
|
Default: 5
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.8" href="#section-4.8.8">4.8.8</a>. ReportInterval</span>
|
|
|
|
The default Report Interval is 120 seconds.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 89]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-90" id="page-90" href="#page-90" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.9" href="#section-4.8.9">4.8.9</a>. RetransmitCount</span>
|
|
|
|
The number of retransmissions for a given CAPWAP packet. This is a
|
|
monotonically increasing counter.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.8.10" href="#section-4.8.10">4.8.10</a>. WTPFallBack</span>
|
|
|
|
The default WTP Fallback value is enabled (1).
|
|
|
|
<span class="h3"><a class="selflink" name="section-4.9" href="#section-4.9">4.9</a>. WTP Saved Variables</span>
|
|
|
|
In addition to the values defined in <a href="#section-4.8">Section 4.8</a>, the following
|
|
values SHOULD be saved on the WTP in non-volatile memory. CAPWAP
|
|
wireless bindings MAY define additional values that SHOULD be stored
|
|
on the WTP.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.1" href="#section-4.9.1">4.9.1</a>. AdminRebootCount</span>
|
|
|
|
The number of times the WTP has rebooted administratively, defined in
|
|
<a href="#section-4.6.48">Section 4.6.48</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.2" href="#section-4.9.2">4.9.2</a>. FrameEncapType</span>
|
|
|
|
For WTPs that support multiple Frame Encapsulation Types, it is
|
|
useful to save the value configured by the AC. The Frame
|
|
Encapsulation Type is defined in <a href="#section-4.6.41">Section 4.6.41</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.3" href="#section-4.9.3">4.9.3</a>. LastRebootReason</span>
|
|
|
|
The reason why the WTP last rebooted, defined in <a href="#section-4.6.48">Section 4.6.48</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.4" href="#section-4.9.4">4.9.4</a>. MacType</span>
|
|
|
|
For WTPs that support multiple MAC Types, it is useful to save the
|
|
value configured by the AC. The MACType is defined in
|
|
<a href="#section-4.6.44">Section 4.6.44</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.5" href="#section-4.9.5">4.9.5</a>. PreferredACs</span>
|
|
|
|
The preferred ACs, with the index, defined in <a href="#section-4.6.5">Section 4.6.5</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.6" href="#section-4.9.6">4.9.6</a>. RebootCount</span>
|
|
|
|
The number of times the WTP has rebooted, defined in <a href="#section-4.6.48">Section 4.6.48</a>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 90]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-91" id="page-91" href="#page-91" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.7" href="#section-4.9.7">4.9.7</a>. Static ACL Table</span>
|
|
|
|
The static ACL table saved on the WTP, as configured by the Add
|
|
Static MAC ACL Entry message element, see <a href="#section-4.6.9">Section 4.6.9</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.8" href="#section-4.9.8">4.9.8</a>. Static IP Address</span>
|
|
|
|
The static IP Address assigned to the WTP, as configured by the WTP
|
|
Static IP Address Information message element (see <a href="#section-4.6.49">Section 4.6.49</a>).
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.9" href="#section-4.9.9">4.9.9</a>. WTPLinkFailureCount</span>
|
|
|
|
The number of times the link to the AC has failed, see
|
|
<a href="#section-4.6.48">Section 4.6.48</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.10" href="#section-4.9.10">4.9.10</a>. WTPLocation</span>
|
|
|
|
The WTP Location, defined in <a href="#section-4.6.28">Section 4.6.28</a>.
|
|
|
|
<span class="h4"><a class="selflink" name="section-4.9.11" href="#section-4.9.11">4.9.11</a>. WTPName</span>
|
|
|
|
The WTP Name, defined in <a href="#section-4.6.45">Section 4.6.45</a>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 91]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-92" id="page-92" href="#page-92" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-5" href="#section-5">5</a>. CAPWAP Discovery Operations</span>
|
|
|
|
The Discovery messages are used by a WTP to determine which ACs are
|
|
available to provide service, and the capabilities and load of the
|
|
ACs.
|
|
|
|
<span class="h3"><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. Discovery Request Message</span>
|
|
|
|
The Discovery Request message is used by the WTP to automatically
|
|
discover potential ACs available in the network. The Discovery
|
|
Request message provides ACs with the primary capabilities of the
|
|
WTP. A WTP must exchange this information to ensure subsequent
|
|
exchanges with the ACs are consistent with the WTP's functional
|
|
characteristics.
|
|
|
|
Discovery Request messages MUST be sent by a WTP in the Discover
|
|
state after waiting for a random delay less than
|
|
MaxDiscoveryInterval, after a WTP first comes up or is
|
|
(re)initialized. A WTP MUST send no more than the maximum of
|
|
MaxDiscoveries Discovery Request messages, waiting for a random delay
|
|
less than MaxDiscoveryInterval between each successive message.
|
|
|
|
This is to prevent an explosion of WTP Discovery Request messages.
|
|
An example of this occurring is when many WTPs are powered on at the
|
|
same time.
|
|
|
|
Discovery Request messages MUST be sent by a WTP when no Echo
|
|
Response messages are received for NeighborDeadInterval and the WTP
|
|
returns to the Idle state. Discovery Request messages are sent after
|
|
NeighborDeadInterval. They MUST be sent after waiting for a random
|
|
delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum
|
|
of MaxDiscoveries Discovery Request messages, waiting for a random
|
|
delay less than MaxDiscoveryInterval between each successive message.
|
|
|
|
If a Discovery Response message is not received after sending the
|
|
maximum number of Discovery Request messages, the WTP enters the
|
|
Sulking state and MUST wait for an interval equal to SilentInterval
|
|
before sending further Discovery Request messages.
|
|
|
|
Upon receiving a Discovery Request message, the AC will respond with
|
|
a Discovery Response message sent to the address in the source
|
|
address of the received Discovery Request message.
|
|
|
|
It is possible for the AC to receive a cleartext Discovery Request
|
|
message while a DTLS session is already active with the WTP. This is
|
|
most likely the case if the WTP has rebooted, perhaps due to a
|
|
software or power failure, but could also be caused by a DoS attack.
|
|
In such cases, any WTP state, including the state machine instance,
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 92]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-93" id="page-93" href="#page-93" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
MUST NOT be cleared until another DTLS session has been successfully
|
|
established, communicated via the DTLSSessionEstablished DTLS
|
|
notification (see <a href="#section-2.3.2.2">Section 2.3.2.2</a>).
|
|
|
|
The binding specific WTP Radio Information message element (see
|
|
<a href="#section-2.1">Section 2.1</a>) is included in the Discovery Request message to
|
|
advertise WTP support for one or more CAPWAP bindings.
|
|
|
|
The Discovery Request message is sent by the WTP when in the
|
|
Discovery State. The AC does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Discovery
|
|
Request message:
|
|
|
|
o Discovery Type, see <a href="#section-4.6.20">Section 4.6.20</a>
|
|
|
|
o WTP Board Data, see <a href="#section-4.6.38">Section 4.6.38</a>
|
|
|
|
o WTP Descriptor, see <a href="#section-4.6.39">Section 4.6.39</a>
|
|
|
|
o WTP Frame Tunnel Mode, see <a href="#section-4.6.41">Section 4.6.41</a>
|
|
|
|
o WTP MAC Type, see <a href="#section-4.6.44">Section 4.6.44</a>
|
|
|
|
o WTP Radio Information message element(s)that the WTP supports;
|
|
These are defined by the individual link layer CAPWAP Binding
|
|
Protocols (see <a href="#section-2.1">Section 2.1</a>).
|
|
|
|
<span class="h3"><a class="selflink" name="section-5.2" href="#section-5.2">5.2</a>. Discovery Response Message</span>
|
|
|
|
The Discovery Response message provides a mechanism for an AC to
|
|
advertise its services to requesting WTPs.
|
|
|
|
When a WTP receives a Discovery Response message, it MUST wait for an
|
|
interval not less than DiscoveryInterval for receipt of additional
|
|
Discovery Response messages. After the DiscoveryInterval elapses,
|
|
the WTP enters the DTLS-Init state and selects one of the ACs that
|
|
sent a Discovery Response message and send a DTLS Handshake to that
|
|
AC.
|
|
|
|
One or more binding specific WTP Radio Information message elements
|
|
(see <a href="#section-2.1">Section 2.1</a>) are included in the Discovery Request message to
|
|
advertise AC support for the CAPWAP bindings. The AC MAY include
|
|
only the bindings it shares in common with the WTP, known through the
|
|
WTP Radio Information message elements received in the Discovery
|
|
Request message, or it MAY include all of the bindings supported.
|
|
The WTP MAY use the supported bindings in its AC decision process.
|
|
Note that if the WTP joins an AC that does not support a specific
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 93]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-94" id="page-94" href="#page-94" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
CAPWAP binding, service for that binding MUST NOT be provided by the
|
|
WTP.
|
|
|
|
The Discovery Response message is sent by the AC when in the Idle
|
|
State. The WTP does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Discovery
|
|
Response Message:
|
|
|
|
o AC Descriptor, see <a href="#section-4.6.1">Section 4.6.1</a>
|
|
|
|
o AC Name, see <a href="#section-4.6.4">Section 4.6.4</a>
|
|
|
|
o WTP Radio Information message element(s)that the AC supports;
|
|
These are defined by the individual link layer CAPWAP Binding
|
|
Protocols (see <a href="#section-2.1">Section 2.1</a> for more information).
|
|
|
|
o One of the following message elements MUST be included in the
|
|
Discovery Response Message:
|
|
|
|
* CAPWAP Control IPv4 Address, see <a href="#section-4.6.10">Section 4.6.10</a>
|
|
|
|
* CAPWAP Control IPv6 Address, see <a href="#section-4.6.11">Section 4.6.11</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-5.3" href="#section-5.3">5.3</a>. Primary Discovery Request Message</span>
|
|
|
|
The Primary Discovery Request message is sent by the WTP to determine
|
|
whether its preferred (or primary) AC is available.
|
|
|
|
A Primary Discovery Request message is sent by a WTP when it has a
|
|
primary AC configured, and is connected to another AC. This
|
|
generally occurs as a result of a failover, and is used by the WTP as
|
|
a means to discover when its primary AC becomes available. Since the
|
|
WTP only has a single instance of the CAPWAP state machine, the
|
|
Primary Discovery Request is sent by the WTP when in the Run State.
|
|
The AC does not transmit this message.
|
|
|
|
The frequency of the Primary Discovery Request messages should be no
|
|
more often than the sending of the Echo Request message.
|
|
|
|
Upon receipt of a Primary Discovery Request message, the AC responds
|
|
with a Primary Discovery Response message sent to the address in the
|
|
source address of the received Primary Discovery Request message.
|
|
|
|
The following message elements MUST be included in the Primary
|
|
Discovery Request message.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 94]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-95" id="page-95" href="#page-95" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o Discovery Type, see <a href="#section-4.6.20">Section 4.6.20</a>
|
|
|
|
o WTP Board Data, see <a href="#section-4.6.38">Section 4.6.38</a>
|
|
|
|
o WTP Descriptor, see <a href="#section-4.6.39">Section 4.6.39</a>
|
|
|
|
o WTP Frame Tunnel Mode, see <a href="#section-4.6.41">Section 4.6.41</a>
|
|
|
|
o WTP MAC Type, see <a href="#section-4.6.44">Section 4.6.44</a>
|
|
|
|
o WTP Radio Information message element(s)that the WTP supports;
|
|
These are defined by the individual link layer CAPWAP Binding
|
|
Protocols (see <a href="#section-2.1">Section 2.1</a> for more information).
|
|
|
|
<span class="h3"><a class="selflink" name="section-5.4" href="#section-5.4">5.4</a>. Primary Discovery Response</span>
|
|
|
|
The Primary Discovery Response message enables an AC to advertise its
|
|
availability and services to requesting WTPs that are configured to
|
|
have the AC as its primary AC.
|
|
|
|
The Primary Discovery Response message is sent by an AC after
|
|
receiving a Primary Discovery Request message.
|
|
|
|
When a WTP receives a Primary Discovery Response message, it may
|
|
establish a CAPWAP protocol connection to its primary AC, based on
|
|
the configuration of the WTP Fallback Status message element on the
|
|
WTP.
|
|
|
|
The Primary Discovery Response message is sent by the AC when in the
|
|
Idle State. The WTP does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Primary
|
|
Discovery Response message.
|
|
|
|
o AC Descriptor, see <a href="#section-4.6.1">Section 4.6.1</a>
|
|
|
|
o AC Name, see <a href="#section-4.6.4">Section 4.6.4</a>
|
|
|
|
o WTP Radio Information message element(s)that the AC supports;
|
|
These are defined by the individual link layer CAPWAP Binding
|
|
Protocols (see <a href="#section-2.1">Section 2.1</a> for more information).
|
|
|
|
One of the following message elements MUST be included in the
|
|
Discovery Response Message:
|
|
|
|
o CAPWAP Control IPv4 Address, see <a href="#section-4.6.10">Section 4.6.10</a>
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 95]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-96" id="page-96" href="#page-96" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o CAPWAP Control IPv6 Address, see <a href="#section-4.6.11">Section 4.6.11</a>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 96]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-97" id="page-97" href="#page-97" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-6" href="#section-6">6</a>. CAPWAP Join Operations</span>
|
|
|
|
The Join Request message is used by a WTP to request service from an
|
|
AC after a DTLS connection is established to that AC. The Join
|
|
Response message is used by the the AC to indicate that it will or
|
|
will not provide service.
|
|
|
|
<span class="h3"><a class="selflink" name="section-6.1" href="#section-6.1">6.1</a>. Join Request</span>
|
|
|
|
The Join Request message is used by a WTP to request service through
|
|
the AC. A Join Request message is sent by a WTP after (optionally)
|
|
receiving one or more Discovery Response messages, and completion of
|
|
DTLS session establishment. When an AC receives a Join Request
|
|
message it responds with a Join Response message.
|
|
|
|
Upon completion of the DTLS handshake, and receiving the
|
|
DTLSEstablished notification, the WTP sends the Join Request message
|
|
to the AC. When the AC is notified of the DTLS session
|
|
establishment, it does not clear the WaitDTLS timer until it has
|
|
received the Join Request message, at which time it sends a Join
|
|
Response message to the WTP, indicating success or failure.
|
|
|
|
One or more WTP Radio Information message elements (see <a href="#section-2.1">Section 2.1</a>)
|
|
are included in the Join Request to request service for the CAPWAP
|
|
bindings by the AC. Including a binding that is unsupported by the
|
|
AC will result in a failed Join Response.
|
|
|
|
If the AC rejects the Join Request, it sends a Join Response message
|
|
with a failure indication and initiates an abort of the DTLS session
|
|
via the DTLSAbort command.
|
|
|
|
If an invalid (i.e. malformed) Join Request message is received, the
|
|
message MUST be silently discarded by the AC. No response is sent to
|
|
the WTP. The AC SHOULD log this event.
|
|
|
|
The Join Request is sent by the WTP when in the Join State. The AC
|
|
does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Join Request
|
|
message.
|
|
|
|
o Location Data, see <a href="#section-4.6.28">Section 4.6.28</a>
|
|
|
|
o WTP Board Data, see <a href="#section-4.6.38">Section 4.6.38</a>
|
|
|
|
o WTP Descriptor, see <a href="#section-4.6.39">Section 4.6.39</a>
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 97]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-98" id="page-98" href="#page-98" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o WTP Name, see <a href="#section-4.6.45">Section 4.6.45</a>
|
|
|
|
o Session ID, see <a href="#section-4.6.35">Section 4.6.35</a>
|
|
|
|
o WTP Frame Tunnel Mode, see <a href="#section-4.6.41">Section 4.6.41</a>
|
|
|
|
o WTP MAC Type, see <a href="#section-4.6.44">Section 4.6.44</a>
|
|
|
|
o WTP Radio Information message element(s)that the WTP supports;
|
|
These are defined by the individual link layer CAPWAP Binding
|
|
Protocols (see <a href="#section-2.1">Section 2.1</a> for more information).
|
|
|
|
At least one of the following message element MUST be included in the
|
|
Join Request message.
|
|
|
|
o WTP IPv4 IP Address, see <a href="#section-4.6.42">Section 4.6.42</a>
|
|
|
|
o WTP IPv6 IP Address, see <a href="#section-4.6.43">Section 4.6.43</a>
|
|
|
|
The following message element MAY be included in the Join Request
|
|
message.
|
|
|
|
o Maximum Message Length, see <a href="#section-4.6.29">Section 4.6.29</a>
|
|
|
|
o WTP Reboot Statistics, see <a href="#section-4.6.48">Section 4.6.48</a>
|
|
|
|
o WTP IPv4 IP Address, see <a href="#section-4.6.42">Section 4.6.42</a>
|
|
|
|
o WTP IPv6 IP Address, see <a href="#section-4.6.43">Section 4.6.43</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-6.2" href="#section-6.2">6.2</a>. Join Response</span>
|
|
|
|
The Join Response message is sent by the AC to indicate to a WTP that
|
|
it is capable and willing to provide service to the WTP.
|
|
|
|
The WTP, receiving a Join Response message, checks for success or
|
|
failure. If the message indicates success, the WTP clears the
|
|
WaitDTLS timer for the session and proceeds to the Configure state.
|
|
|
|
If the WaitDTLS Timer expires prior to reception of the Join Response
|
|
message, the WTP MUST terminate the handshake, deallocate session
|
|
state and initiate the DTLSAbort command.
|
|
|
|
If an invalid (malformed) Join Response message is received, the WTP
|
|
SHOULD log an informative message detailing the error. This error
|
|
MUST be treated in the same manner as AC non-responsiveness. The
|
|
WaitDTLS timer will eventually expire, and the WTP MAY (if it is so
|
|
configured) attempts to join a new AC.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 98]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-99" id="page-99" href="#page-99" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
If one of the WTP Radio Information message elements (see
|
|
<a href="#section-2.1">Section 2.1</a>) in the Join Request message requested support for a
|
|
CAPWAP binding which the AC does not support, the AC sets the Result
|
|
Code message element to "Binding Not Supported".
|
|
|
|
The AC includes the Image Identifier message element to indicate the
|
|
software version it expects the WTP to run. This information is used
|
|
to determine whether the WTP MUST either change its currently running
|
|
firmware image, or download a new version (see <a href="#section-9.1.1">Section 9.1.1</a>).
|
|
|
|
The Join Response message is sent by the AC when in the Join State.
|
|
The WTP does not transmit this message.
|
|
|
|
The following message elements MAY be included in the Join Response
|
|
message.
|
|
|
|
o AC IPv4 List, see <a href="#section-4.6.2">Section 4.6.2</a>
|
|
|
|
o AC IPv6 List, see <a href="#section-4.6.3">Section 4.6.3</a>
|
|
|
|
o Image Identifier, see <a href="#section-4.6.25">Section 4.6.25</a>
|
|
|
|
o Maximum Message Length, see <a href="#section-4.6.29">Section 4.6.29</a>
|
|
|
|
The following message elements MUST be included in the Join Response
|
|
message.
|
|
|
|
o Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
o AC Descriptor, see <a href="#section-4.6.1">Section 4.6.1</a>
|
|
|
|
o AC Name, see <a href="#section-4.6.4">Section 4.6.4</a>
|
|
|
|
o WTP Radio Information message element(s)that the AC supports;
|
|
These are defined by the individual link layer CAPWAP Binding
|
|
Protocols (see <a href="#section-2.1">Section 2.1</a>).
|
|
|
|
One of the following message elements MUST be included in the
|
|
Discovery Response Message:
|
|
|
|
o CAPWAP Control IPv4 Address, see <a href="#section-4.6.10">Section 4.6.10</a>
|
|
|
|
o CAPWAP Control IPv6 Address, see <a href="#section-4.6.11">Section 4.6.11</a>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 99]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-100" id="page-100" href="#page-100" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-7" href="#section-7">7</a>. Control Channel Management</span>
|
|
|
|
The Control Channel Management messages are used by the WTP and AC to
|
|
maintain a control communication channel. CAPWAP control messages,
|
|
such as the WTP Event Request message sent from the WTP to the AC
|
|
indicate to the AC that the WTP is operational. When such control
|
|
messages are not being sent, the Echo Request and Echo Response
|
|
messages are used to maintain the control communication channel.
|
|
|
|
<span class="h3"><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>. Echo Request</span>
|
|
|
|
The Echo Request message is a keep-alive mechanism for CAPWAP control
|
|
messages.
|
|
|
|
Echo Request messages are sent periodically by a WTP in the Run state
|
|
(see <a href="#section-2.3">Section 2.3</a>) to determine the state of the control connection
|
|
between the WTP and the AC. The Echo Request message is sent by the
|
|
WTP when the EchoInterval timer expires. The WTP MUST start its
|
|
NeighborDeadInterval timer when the EchoInterval timer expires.
|
|
|
|
The Echo Request message is sent by the WTP when in the Run State.
|
|
The AC does not transmit this message.
|
|
|
|
The Echo Request message carries no message elements.
|
|
|
|
When an AC receives an Echo Request message it responds with an Echo
|
|
Response message.
|
|
|
|
<span class="h3"><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>. Echo Response</span>
|
|
|
|
The Echo Response message acknowledges the Echo Request message.
|
|
|
|
An Echo Response message is sent by an AC after receiving an
|
|
EchoRequest message. After transmitting the Echo Response message,
|
|
the AC SHOULD reset its EchoInterval timer. If another Echo Request
|
|
message or other control message is not received by the AC when the
|
|
timer expires, the AC SHOULD consider the WTP to be no longer
|
|
reachable.
|
|
|
|
The Echo Response message is sent by the AC when in the Run State.
|
|
The WTP does not transmit this message.
|
|
|
|
The Echo Response message carries no message elements.
|
|
|
|
When a WTP receives an Echo Response message it stops the
|
|
NeighborDeadInterval timer, and initializes the EchoInterval to the
|
|
configured value.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 100]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-101" id="page-101" href="#page-101" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
If the NeighborDeadInterval timer expires prior to receiving an Echo
|
|
Response message, or other control message, the WTP enters the Idle
|
|
state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 101]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-102" id="page-102" href="#page-102" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-8" href="#section-8">8</a>. WTP Configuration Management</span>
|
|
|
|
WTP Configuration messages are used to exchange configuration
|
|
information between the AC and the WTP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.1" href="#section-8.1">8.1</a>. Configuration Consistency</span>
|
|
|
|
The CAPWAP protocol provides flexibility in how WTP configuration is
|
|
managed. A WTP has two options:
|
|
|
|
1. The WTP retains no configuration and accepts the configuration
|
|
provided by the AC.
|
|
|
|
2. The WTP retains the configuration of parameters provided by the AC
|
|
that are non-default values.
|
|
|
|
If the WTP opts to save configuration locally, the CAPWAP protocol
|
|
state machine defines the Configure state, which allows for
|
|
configuration exchange. In the Configure state, the WTP sends its
|
|
current configuration overrides to the AC via the Configuration
|
|
Status message. A configuration override is a non-default parameter.
|
|
As an example, in the CAPWAP protocol, the default antenna
|
|
configuration is internal omni antenna. A WTP that either has no
|
|
internal antennas, or has been explicitly configured by the AC to use
|
|
external antennas, sends its antenna configuration during the
|
|
configure phase, allowing the AC to become aware of the WTP's current
|
|
configuration.
|
|
|
|
Once the WTP has provided its configuration to the AC, the AC sends
|
|
its configuration to the WTP. This allows the WTP to receive
|
|
configuration and policies from the AC.
|
|
|
|
The AC maintains a copy of each active WTP configuration. There is
|
|
no need for versioning or other means to identify configuration
|
|
changes. If a WTP becomes inactive, the AC MAY delete the inactive
|
|
WTP configuration. If a WTP fails, and connects to a new AC, the WTP
|
|
provides its overridden configuration parameters, allowing the new AC
|
|
to be aware of the WTP configuration.
|
|
|
|
This model allows for resiliency in case of an AC failure, ensuring
|
|
another AC can provide service to the WTP. A new AC would be
|
|
automatically updated with WTP configuration changes, eliminating the
|
|
need for inter-AC communication and the need for all ACs to be aware
|
|
of the configuration of all WTPs in the network.
|
|
|
|
Once the CAPWAP protocol enters the Run state, the WTPs begin to
|
|
provide service. It is common for administrators to require that
|
|
configuration changes be made while the network is operational.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 102]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-103" id="page-103" href="#page-103" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Therefore, the Configuration Update Request is sent by the AC to the
|
|
WTP to make these changes at run-time.
|
|
|
|
<span class="h4"><a class="selflink" name="section-8.1.1" href="#section-8.1.1">8.1.1</a>. Configuration Flexibility</span>
|
|
|
|
The CAPWAP protocol provides the flexibility to configure and manage
|
|
WTPs of varying design and functional characteristics. When a WTP
|
|
first discovers an AC, it provides primary functional information
|
|
relating to its type of MAC and to the nature of frames to be
|
|
exchanged. The AC configures the WTP appropriately. The AC also
|
|
establishes corresponding internal state for the WTP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.2" href="#section-8.2">8.2</a>. Configuration Status</span>
|
|
|
|
The Configuration Status message is sent by a WTP to deliver its
|
|
current configuration to the AC.
|
|
|
|
The Configuration Status message carries binding specific message
|
|
elements. Refer to the appropriate binding for the definition of
|
|
this structure.
|
|
|
|
When an AC receives a Configuration Status message it acts upon the
|
|
content of the message and responds to the WTP with a Configuration
|
|
Status Response message.
|
|
|
|
The Configuration Status message includes multiple Radio
|
|
Administrative State message elements, one for the WTP, and one for
|
|
each radio in the WTP.
|
|
|
|
The Configuration Status message is sent by the WTP when in the
|
|
Configure State. The AC does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Configuration
|
|
Status message.
|
|
|
|
o AC Name, see <a href="#section-4.6.4">Section 4.6.4</a>
|
|
|
|
o AC Name with Index, see <a href="#section-4.6.5">Section 4.6.5</a>
|
|
|
|
o Radio Administrative State, see <a href="#section-4.6.31">Section 4.6.31</a>
|
|
|
|
o Statistics Timer, see <a href="#section-4.6.36">Section 4.6.36</a>
|
|
|
|
o WTP Reboot Statistics, see <a href="#section-4.6.48">Section 4.6.48</a>
|
|
|
|
The following message elements MAY be included in the Configuration
|
|
Status message.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 103]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-104" id="page-104" href="#page-104" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o WTP Static IP Address Information, see <a href="#section-4.6.49">Section 4.6.49</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.3" href="#section-8.3">8.3</a>. Configuration Status Response</span>
|
|
|
|
The Configuration Status Response message is sent by an AC and
|
|
provides a mechanism for the AC to override a WTP's requested
|
|
configuration.
|
|
|
|
A Configuration Status Response message is sent by an AC after
|
|
receiving a Configuration Request message.
|
|
|
|
The Configuration Status Response message carries binding specific
|
|
message elements. Refer to the appropriate binding for the
|
|
definition of this structure.
|
|
|
|
When a WTP receives a Configuration Status Response message it acts
|
|
upon the content of the message, as appropriate. If the
|
|
Configuration Status Response message includes a Radio Operational
|
|
State message element that causes a change in the operational state
|
|
of one of the radios, the WTP transmits a Change State Event to the
|
|
AC, as an acknowledgement of the change in state.
|
|
|
|
The Configuration Status Response message is sent by the AC when in
|
|
the Configure State. The WTP does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Configuration
|
|
Status Response message.
|
|
|
|
o AC IPv4 List, see <a href="#section-4.6.2">Section 4.6.2</a>
|
|
|
|
o AC IPv6 List, see <a href="#section-4.6.3">Section 4.6.3</a>
|
|
|
|
o CAPWAP Timers, see <a href="#section-4.6.12">Section 4.6.12</a>
|
|
|
|
o Decryption Error Report Period, see <a href="#section-4.6.16">Section 4.6.16</a>
|
|
|
|
o Idle Timeout, see <a href="#section-4.6.23">Section 4.6.23</a>
|
|
|
|
o WTP Fallback, see <a href="#section-4.6.40">Section 4.6.40</a>
|
|
|
|
The following message element MAY be included in the Configuration
|
|
Status Response message.
|
|
|
|
o WTP Static IP Address Information, see <a href="#section-4.6.49">Section 4.6.49</a>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 104]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-105" id="page-105" href="#page-105" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.4" href="#section-8.4">8.4</a>. Configuration Update Request</span>
|
|
|
|
Configuration Update Request messages are sent by the AC to provision
|
|
the WTP while in the Run state. This is used to modify the
|
|
configuration of the WTP while it is operational.
|
|
|
|
When a WTP receives a Configuration Update Request message, it
|
|
responds with a Configuration Update Response message, with a Result
|
|
Code message element indicating the result of the configuration
|
|
request.
|
|
|
|
The AC includes the Image Identifier and Initiate Download message
|
|
elements to force the WTP to update its firmware while in the Run
|
|
state. The WTP MAY proceed to download the requested firmware if it
|
|
determines the version specified in the Image Identifier message
|
|
element is not in its non-volatile storage (see <a href="#section-9.1.1">Section 9.1.1</a>).
|
|
|
|
The Configuration Update Request is sent by the AC when in the Run
|
|
State. The WTP does not transmit this message.
|
|
|
|
One or more of the following message elements MAY be included in the
|
|
Configuration Update message.
|
|
|
|
o AC Name with Index, see <a href="#section-4.6.5">Section 4.6.5</a>
|
|
|
|
o AC Timestamp, see <a href="#section-4.6.6">Section 4.6.6</a>
|
|
|
|
o Add MAC ACL Entry, see <a href="#section-4.6.7">Section 4.6.7</a>
|
|
|
|
o Add Static MAC ACL Entry, see <a href="#section-4.6.9">Section 4.6.9</a>
|
|
|
|
o CAPWAP Timers, see <a href="#section-4.6.12">Section 4.6.12</a>
|
|
|
|
o Decryption Error Report Period, see <a href="#section-4.6.16">Section 4.6.16</a>
|
|
|
|
o Delete MAC ACL Entry, see <a href="#section-4.6.17">Section 4.6.17</a>
|
|
|
|
o Delete Static MAC ACL Entry, see <a href="#section-4.6.19">Section 4.6.19</a>
|
|
|
|
o Idle Timeout, see <a href="#section-4.6.23">Section 4.6.23</a>
|
|
|
|
o Location Data, see <a href="#section-4.6.28">Section 4.6.28</a>
|
|
|
|
o Radio Administrative State, see <a href="#section-4.6.31">Section 4.6.31</a>
|
|
|
|
o Statistics Timer, see <a href="#section-4.6.36">Section 4.6.36</a>
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 105]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-106" id="page-106" href="#page-106" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o WTP Fallback, see <a href="#section-4.6.40">Section 4.6.40</a>
|
|
|
|
o WTP Name, see <a href="#section-4.6.45">Section 4.6.45</a>
|
|
|
|
o WTP Static IP Address Information, see <a href="#section-4.6.49">Section 4.6.49</a>
|
|
|
|
o Image Identifier, see <a href="#section-4.6.25">Section 4.6.25</a>
|
|
|
|
o Initiate Download, see <a href="#section-4.6.27">Section 4.6.27</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.5" href="#section-8.5">8.5</a>. Configuration Update Response</span>
|
|
|
|
The Configuration Update Response message is the acknowledgement
|
|
message for the Configuration Update Request message.
|
|
|
|
The Configuration Update Response message is sent by a WTP after
|
|
receiving a Configuration Update Request message.
|
|
|
|
When an AC receives a Configuration Update Response message the
|
|
result code indicates if the WTP successfully accepted the
|
|
configuration.
|
|
|
|
The Configuration Update Response message is sent by the WTP when in
|
|
the Run State. The AC does not transmit this message.
|
|
|
|
The following message element MUST be present in the Configuration
|
|
Update message.
|
|
|
|
Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
The following message elements MAY be present in the Configuration
|
|
Update Response message.
|
|
|
|
o Radio Operational State, see <a href="#section-4.6.32">Section 4.6.32</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.6" href="#section-8.6">8.6</a>. Change State Event Request</span>
|
|
|
|
The Change State Event Request message is used by the WTP for two
|
|
main purposes:
|
|
|
|
o When sent by the WTP following the reception of a Configuration
|
|
Status Response message from the AC, the WTP uses the Change State
|
|
Event Request message to provide an update on the WTP radio's
|
|
operational state and to confirm that the configuration provided
|
|
by the AC was successfully applied.
|
|
|
|
o When sent during the Run state, the WTP uses the Change State
|
|
Event Request message to notify the AC of an unexpected change in
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 106]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-107" id="page-107" href="#page-107" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
the WTP's radio operational state.
|
|
|
|
When an AC receives a Change State Event Request message it responds
|
|
with a Change State Event Response message and modifies its data
|
|
structures for the WTP as needed. The AC MAY decide not to provide
|
|
service to the WTP if it receives an error, based on local policy,
|
|
and to transition to the Reset state.
|
|
|
|
The Change State Event Request message is sent by a WTP to
|
|
acknowledge or report an error condition to the AC for a requested
|
|
configuration in the Configuration Status Response message. The
|
|
Change State Event Request message includes the Result Code message
|
|
element, which indicates whether the configuration was successfully
|
|
applied. If the WTP is unable to apply a specfic configuration
|
|
request, it indicates the failure by including one or more Returned
|
|
Message Element message elements (see <a href="#section-4.6.34">Section 4.6.34</a>).
|
|
|
|
The Change State Event Request message is sent by the WTP in the
|
|
Configure or Run State. The AC does not transmit this message.
|
|
|
|
The WTP MAY save its configuration to persistent storage prior to
|
|
transmitting the response. However, this is implementation specific
|
|
and is not required.
|
|
|
|
The following message elements MUST be present in the Change State
|
|
Event Request message.
|
|
|
|
o Radio Operational State, see <a href="#section-4.6.32">Section 4.6.32</a>
|
|
|
|
o Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
One or more of the following message elements MAY be present in the
|
|
Change State Event Request message.
|
|
|
|
o Returned Message Element(s), see <a href="#section-4.6.34">Section 4.6.34</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.7" href="#section-8.7">8.7</a>. Change State Event Response</span>
|
|
|
|
The Change State Event Response message acknowledges the Change State
|
|
Event Request message.
|
|
|
|
A Change State Event Response message is sent by an AC in response to
|
|
a Change State Event Request message.
|
|
|
|
The Change State Event Response message is sent by the AC when in the
|
|
Configure or Run state. The WTP does not transmit this message.
|
|
|
|
The Change State Event Response message carries no message elements.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 107]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-108" id="page-108" href="#page-108" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
The WTP does not take any action upon receipt of the Change State
|
|
Event Response message.
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.8" href="#section-8.8">8.8</a>. Clear Configuration Request</span>
|
|
|
|
The Clear Configuration Request message is used to reset the WTP
|
|
configuration.
|
|
|
|
The Clear Configuration Request message is sent by an AC to request
|
|
that a WTP reset its configuration to the manufacturing default
|
|
configuration. The Clear Config Request message is sent while in the
|
|
Run state.
|
|
|
|
The Clear Configuration Request is sent by the AC when in the Run
|
|
State. The WTP does not transmit this message.
|
|
|
|
The Clear Configuration Request message carries no message elements.
|
|
|
|
When a WTP receives a Clear Configuration Request message it resets
|
|
its configuration to the manufacturing default configuration.
|
|
|
|
<span class="h3"><a class="selflink" name="section-8.9" href="#section-8.9">8.9</a>. Clear Configuration Response</span>
|
|
|
|
The Clear Configuration Response message is sent by the WTP after
|
|
receiving a Clear Configuration Request message and resetting its
|
|
configuration parameters to the manufacturing default values.
|
|
|
|
The Clear Configuration Response is sent by the WTP when in the Run
|
|
State. The AC does not transmit this message.
|
|
|
|
The Clear Configuration Request message MUST include the following
|
|
message element.
|
|
|
|
o Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 108]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-109" id="page-109" href="#page-109" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-9" href="#section-9">9</a>. Device Management Operations</span>
|
|
|
|
This section defines CAPWAP operations responsible for debugging,
|
|
gathering statistics, logging, and firmware management.
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.1" href="#section-9.1">9.1</a>. Firmware Management</span>
|
|
|
|
This section describes the firmware download procedures used by the
|
|
CAPWAP protocol. Firmware download can occur during the Image Data
|
|
or Run state.
|
|
|
|
Figure 4 provides an example of a WTP that performs a firmware
|
|
upgrade while in the Image Data state. In this example, the WTP does
|
|
not already have the requested firmware (Image Identifier = x), and
|
|
downloads the image from the AC.
|
|
|
|
WTP AC
|
|
|
|
Join Request
|
|
-------------------------------------------------------->
|
|
|
|
Join Response (Image Identifier = x)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Request (Image Identifier = x)
|
|
-------------------------------------------------------->
|
|
|
|
Image Data Response (Result Code = Success,
|
|
Image Information = {size,hash},
|
|
Initiate Download)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Request (Image Data = Data)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
.....
|
|
|
|
Image Data Request (Image Data = EOF)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
(WTP enters the Reset State)
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 109]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-110" id="page-110" href="#page-110" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Figure 4: WTP Firmware Download Case 1
|
|
|
|
Figure 5 provides an example in which the WTP has the image specified
|
|
by the AC in its non-volative storage. The WTP opts to NOT download
|
|
the firmware and immediately reset.
|
|
|
|
WTP AC
|
|
|
|
Join Request
|
|
-------------------------------------------------------->
|
|
|
|
Join Response (Image Identifier = x)
|
|
<------------------------------------------------------
|
|
|
|
(WTP enters the Reset State)
|
|
|
|
Figure 5: WTP Firmware Download Case 2
|
|
|
|
Figure 6 provides an example of a WTP that performs a firmware
|
|
upgrade while in the Run state. This mode of firmware upgrade allows
|
|
the WTP to download its image while continuing to provide service.
|
|
The WTP will not automatically reset until it is notified by the AC,
|
|
with a Reset Request message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 110]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-111" id="page-111" href="#page-111" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
WTP AC
|
|
|
|
Configuration Update Request (Image Identifier = x)
|
|
<------------------------------------------------------
|
|
|
|
Configuration Update Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
|
|
Image Data Request (Image Identifier = x)
|
|
-------------------------------------------------------->
|
|
|
|
Image Data Response (Result Code = Success,
|
|
Image Information = {size,hash},
|
|
Initiate Download)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Request (Image Data = Data)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
.....
|
|
|
|
Image Data Request (Image Data = EOF)
|
|
<------------------------------------------------------
|
|
|
|
Image Data Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
.....
|
|
|
|
(administratively requested reboot request)
|
|
Reset Request (Image Identifier = x)
|
|
<------------------------------------------------------
|
|
|
|
Reset Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
Figure 6: WTP Firmware Download Case 3
|
|
|
|
Figure 7 provides another example of the firmware download while in
|
|
the Run state. In this example, the WTP already has the image
|
|
specified by the AC in its non-volative storage. The WTP opts to NOT
|
|
download the firmware. The WTP resets upon receipt of a Reset
|
|
Request message from the AC.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 111]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-112" id="page-112" href="#page-112" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
WTP AC
|
|
|
|
Configuration Update Request (Image Identifier = x,
|
|
Image Information = {size,hash},
|
|
Initiate Download)
|
|
<------------------------------------------------------
|
|
|
|
Configuration Update Response (Result Code = Already Have Image)
|
|
-------------------------------------------------------->
|
|
|
|
.....
|
|
|
|
(administratively requested reboot request)
|
|
Reset Request (Image Identifier = x)
|
|
<------------------------------------------------------
|
|
|
|
Reset Response (Result Code = Success)
|
|
-------------------------------------------------------->
|
|
|
|
Figure 7: WTP Firmware Download Case 4
|
|
|
|
<span class="h4"><a class="selflink" name="section-9.1.1" href="#section-9.1.1">9.1.1</a>. Image Data Request</span>
|
|
|
|
The Image Data Request message is used to update firmware on the WTP.
|
|
This message and its companion Response message are used by the AC to
|
|
ensure that the image being run on each WTP is appropriate.
|
|
|
|
Image Data Request messages are exchanged between the WTP and the AC
|
|
to download a new firmware image to the WTP. When a WTP or AC
|
|
receives an Image Data Request message it responds with an Image Data
|
|
Response message. The message elements contained within the Image
|
|
Data Request message are required to determine the intent of the
|
|
request.
|
|
|
|
The decision that new firmware is to be downloaded to the WTP can
|
|
occur in one of two ways:
|
|
|
|
When the WTP joins the AC, the Join Response message includes the
|
|
Image Identifier message element, which informs the WTP of the
|
|
firmware it is expected to run. if the WTP does not currently have
|
|
the requested firmware version, it transmits an Image Data Request
|
|
message, with the appropriate Image Identifier message element.
|
|
If the WTP already has the requested firmware, it simply resets.
|
|
|
|
Once the WTP is in the Run state, it is possible for the AC to
|
|
cause the WTP to initiate a firmware download by sending a
|
|
Configuration Update Request message with the Initiate Download
|
|
and and Image Identifier message elements. The WTP then transmits
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 112]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-113" id="page-113" href="#page-113" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
the Image Data Request message, which includes the Image
|
|
Identifier message element to start the download process. Note
|
|
that when the firmware is downloaded in this way, the WTP does not
|
|
automatically reset after the download is complete. The WTP will
|
|
only reset when it receives a Reset Request message from the AC.
|
|
If the WTP already had the requested firmware version in its non-
|
|
volatile storage, the WTP does not transmit the Image Data Request
|
|
message and responds with a Configuration Update Response message
|
|
with the Result Code set to Image Already Present.
|
|
|
|
Regardless of how the download was initiated, once the AC receives an
|
|
Image Data Request message with the Image Identifier message element,
|
|
it begins the transfer process by transmitting an Image Data Request
|
|
message that includes the Image Data message element. This continues
|
|
until the firmware image has been transfered.
|
|
|
|
The Image Data Request message is sent by the WTP or the AC when in
|
|
the Image Data or Run State.
|
|
|
|
The following message elements MAY be included in the Image Data
|
|
Request message.
|
|
|
|
o Image Data, see <a href="#section-4.6.24">Section 4.6.24</a>
|
|
|
|
o Image Identifier, see <a href="#section-4.6.25">Section 4.6.25</a>
|
|
|
|
<span class="h4"><a class="selflink" name="section-9.1.2" href="#section-9.1.2">9.1.2</a>. Image Data Response</span>
|
|
|
|
The Image Data Response message acknowledges the Image Data Request
|
|
message.
|
|
|
|
An Image Data Response message is sent in response to a received
|
|
Image Data Request message. Its purpose is to acknowledge the
|
|
receipt of the Image Data Request message. The Result Code is
|
|
included to indicate whether a previously sent Image Data Request
|
|
message was invalid.
|
|
|
|
The Image Data Response message is sent by the WTP or the AC when in
|
|
the Image Data or Run State.
|
|
|
|
The following message element MUST be included in the Image Data
|
|
Response message.
|
|
|
|
o Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
The following message elements MAY be included in the Image Data
|
|
Response message.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 113]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-114" id="page-114" href="#page-114" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o Image Information, see <a href="#section-4.6.26">Section 4.6.26</a>
|
|
|
|
o Initiate Download, see <a href="#section-4.6.27">Section 4.6.27</a>
|
|
|
|
Upon receiving an Image Data Response message indicating an error,
|
|
the WTP MAY retransmit a previous Image Data Reqest message, or
|
|
abandon the firmware download to the WTP by transitioning to the
|
|
Reset state.
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.2" href="#section-9.2">9.2</a>. Reset Request</span>
|
|
|
|
The Reset Request message is used to cause a WTP to reboot.
|
|
|
|
A Reset Request message is sent by an AC to cause a WTP to
|
|
reinitialize its operation.
|
|
|
|
The Reset Request is sent by the AC when in the Run State. The WTP
|
|
does not transmit this message.
|
|
|
|
The following message elements MUST be included in the Reset Request
|
|
message.
|
|
|
|
o Image Identifier, see <a href="#section-4.6.25">Section 4.6.25</a>
|
|
|
|
When a WTP receives a Reset Request message, it responds with a Reset
|
|
Response message indicating success and then reinitialize itself. If
|
|
the WTP is unable to write to its non-volatile storage, to ensure
|
|
that it runs the requested software version indicated in the Image
|
|
Identifier message element, it MAY send the appropriate Result Code
|
|
message element, but MUST reboot. If the WTP is unable to reset,
|
|
including a hardware reset, it sends a Reset Response message to the
|
|
AC with a Result Code message element indicating failure. The AC no
|
|
longer provides service to the WTP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.3" href="#section-9.3">9.3</a>. Reset Response</span>
|
|
|
|
The Reset Response message acknowledges the Reset Request message.
|
|
|
|
A Reset Response message is sent by the WTP after receiving a Reset
|
|
Request message.
|
|
|
|
The Reset Response is sent by the WTP when in the Run State. The AC
|
|
does not transmit this message.
|
|
|
|
The following message element MAY be included in the Image Data
|
|
Request message.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 114]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-115" id="page-115" href="#page-115" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
o Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
When an AC receives a successful Reset Response message, it is
|
|
notified that the WTP will reinitialize its operation. An AC that
|
|
receives a Reset Response message indicating failure may opt to no
|
|
longer provide service to the WTP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.4" href="#section-9.4">9.4</a>. WTP Event Request</span>
|
|
|
|
The WTP Event Request message is used by a WTP to send information to
|
|
its AC. The WTP Event Request message MAY be sent periodically, or
|
|
sent in response to an asynchronous event on the WTP. For example, a
|
|
WTP MAY collect statistics and use the WTP Event Request message to
|
|
transmit the statistics to the AC.
|
|
|
|
When an AC receives a WTP Event Request message it will respond with
|
|
a WTP Event Response message.
|
|
|
|
The presence of the Delete Station message element is used by the WTP
|
|
to inform the AC that it is no longer providing service to the
|
|
station. This could be the result of an Idle Timeout (see
|
|
<a href="#section-4.6.23">Section 4.6.23</a>), due to to resource shortages, or some other reason.
|
|
|
|
The WTP Event Request message is sent by the WTP when in the Run
|
|
State. The AC does not transmit this message.
|
|
|
|
The WTP Event Request message MUST contain one of the message
|
|
elements listed below, or a message element that is defined for a
|
|
specific wireless technology. More than one of each messsage element
|
|
listed MAY be included in the WTP Event Request message.
|
|
|
|
o Decryption Error Report, see <a href="#section-4.6.15">Section 4.6.15</a>
|
|
|
|
o Duplicate IPv4 Address, see <a href="#section-4.6.21">Section 4.6.21</a>
|
|
|
|
o Duplicate IPv6 Address, see <a href="#section-4.6.22">Section 4.6.22</a>
|
|
|
|
o WTP Operational Statistics, see <a href="#section-4.6.46">Section 4.6.46</a>
|
|
|
|
o WTP Radio Statistics, see <a href="#section-4.6.47">Section 4.6.47</a>
|
|
|
|
o WTP Reboot Statistics, see <a href="#section-4.6.48">Section 4.6.48</a>
|
|
|
|
o Delete Station, see <a href="#section-4.6.18">Section 4.6.18</a>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 115]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-116" id="page-116" href="#page-116" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.5" href="#section-9.5">9.5</a>. WTP Event Response</span>
|
|
|
|
The WTP Event Response message acknowledges receipt of the WTP Event
|
|
Request message.
|
|
|
|
A WTP Event Response message is sent by an AC after receiving a WTP
|
|
Event Request message.
|
|
|
|
The WTP Event Response message is sent by the AC when in the Run
|
|
State. The WTP does not transmit this message.
|
|
|
|
The WTP Event Response message carries no message elements.
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.6" href="#section-9.6">9.6</a>. Data Transfer Request</span>
|
|
|
|
The Data Transfer Request message is used to deliver debug
|
|
information from the WTP to the AC.
|
|
|
|
Data Transfer Request messages are sent by the WTP to the AC when the
|
|
WTP determines that it has important information to send to the AC.
|
|
For instance, if the WTP detects that its previous reboot was caused
|
|
by a system crash, it can send the crash file to the AC. The remote
|
|
debugger function in the WTP also uses the Data Transfer Request
|
|
message to send console output to the AC for debugging purposes.
|
|
|
|
When the AC receives a Data Transfer Request message it responds to
|
|
the WTP with a Data Transfer Response message. The AC MAY log the
|
|
information received.
|
|
|
|
The Data Transfer Request message is sent by the WTP when in the Run
|
|
State. The AC does not transmit this message.
|
|
|
|
The Data Transfer Request message MUST contain one of the message
|
|
elements listed below.
|
|
|
|
o Data Transfer Data, see <a href="#section-4.6.13">Section 4.6.13</a>
|
|
|
|
o Data Transfer Mode, see <a href="#section-4.6.14">Section 4.6.14</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-9.7" href="#section-9.7">9.7</a>. Data Transfer Response</span>
|
|
|
|
The Data Transfer Response message acknowledges the Data Transfer
|
|
Request message.
|
|
|
|
A Data Transfer Response message is sent in response to a received
|
|
Data Transfer Request message. Its purpose is to acknowledge receipt
|
|
of the Data Transfer Request message.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 116]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-117" id="page-117" href="#page-117" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
The Data Transfer Response message is sent by the AC when in the Run
|
|
State. The WTP does not transmit this message.
|
|
|
|
The Data Transfer Response message carries no message elements.
|
|
|
|
Upon receipt of a Data Transfer Response message, the WTP transmits
|
|
more information, if more information is available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 117]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-118" id="page-118" href="#page-118" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-10" href="#section-10">10</a>. Station Session Management</span>
|
|
|
|
Messages in this section are used by the AC to create, modify or
|
|
delete station session state on the WTPs.
|
|
|
|
<span class="h3"><a class="selflink" name="section-10.1" href="#section-10.1">10.1</a>. Station Configuration Request</span>
|
|
|
|
The Station Configuration Request message is used to create, modify
|
|
or delete station session state on a WTP. The message is sent by the
|
|
AC to the WTP, and MAY contain one or more message elements. The
|
|
message elements for this CAPWAP control message include information
|
|
that is generally highly technology specific. Refer to the
|
|
appropriate binding document for definitions of the messages elements
|
|
that are included in this control message.
|
|
|
|
The Station Configuration Request message is sent by the AC when in
|
|
the Run State. The WTP does not transmit this message.
|
|
|
|
The following CAPWAP Control message elements MAY be included in the
|
|
Station Configuration Request message. More than one of each message
|
|
element listed MAY be included in the Station Configuration Request
|
|
message.
|
|
|
|
o Add Station, see <a href="#section-4.6.8">Section 4.6.8</a>
|
|
|
|
o Delete Station, see <a href="#section-4.6.18">Section 4.6.18</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-10.2" href="#section-10.2">10.2</a>. Station Configuration Response</span>
|
|
|
|
The Station Configuration Response message is used to acknowledge a
|
|
previously received Station Configuration Request message.
|
|
|
|
The Station Configuration Response message is sent by the WTP when in
|
|
the Run State. The AC does not transmit this message.
|
|
|
|
The following message element MUST be present in the Station
|
|
Configuration Response message.
|
|
|
|
o Result Code, see <a href="#section-4.6.33">Section 4.6.33</a>
|
|
|
|
The Result Code message element indicates that the requested
|
|
configuration was successfully applied, or that an error related to
|
|
processing of the Station Configuration Request message occurred on
|
|
the WTP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 118]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-119" id="page-119" href="#page-119" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-11" href="#section-11">11</a>. NAT Considerations</span>
|
|
|
|
There are three specific situations in which a NAT deployment may be
|
|
used in conjunction with a CAPWAP-enabled deployment. The first
|
|
consists of a configuration in which a single WTP is behind a NAT
|
|
system. Since all communication is initiated by the WTP, and all
|
|
communication is performed over IP using two UDP ports, the protocol
|
|
easily traverses NAT systems in this configuration.
|
|
|
|
In the second case, two or more WTPs are deployed behind the same NAT
|
|
system. Here, the AC would receive multiple connection requests from
|
|
the same IP address, and cannot differentiate the originating WTP of
|
|
the connection requests. The CAPWAP Data Check state, which
|
|
establishes the data plane connection and communicates the Data
|
|
Keepalive, includes the Session Identifier message element, which is
|
|
used to bind the control and data plane. Use of the Session
|
|
Identifier message element enables the AC to match the control and
|
|
data plane flows from multiple WTPs behind the same NAT system
|
|
(multiple WTPs sharing the same IP address).
|
|
|
|
In the third configuration, the AC is deployed behind a NAT. Two
|
|
issues exist in this situation. First, an AC communicates its
|
|
interfaces and corresponding WTP load using the CAPWAP Control
|
|
IP(v4/v6) Address message element. This message element is currently
|
|
mandatory, and if NAT compliance becomes an issue, it is possible to
|
|
either:
|
|
|
|
1. Make the CAPWAP Control IP (v4/v6) Address optional, allowing the
|
|
WTP to use the known IP Address. Note that this approach
|
|
eliminates the ability to perform load balancing of WTP across
|
|
ACs, and therefore is not the recommended approach.
|
|
|
|
2. Allow an AC to configure a NAT'ed address for every AC that would
|
|
otherwise be communicated in the CAPWAP Control IP (v4/v6) Address
|
|
message element.
|
|
|
|
3. Require that if a WTP determines that the AC List message element
|
|
contains a set of IP Addresses that are different from the AC IP
|
|
Address the WTP is currently using, then assume that NAT is
|
|
present, and require that the WTP communicate with the AC IP
|
|
Address (and ignore the CAPWAP Control IP (v4/v6) Address message
|
|
element(s)).
|
|
|
|
The CAPWAP protocol allows for all of the AC identities supporting a
|
|
group of WTPs to be communicated through the AC List message element.
|
|
This feature MUST be disabled when the AC is behind a NAT and the IP
|
|
Address that is embedded is invalid.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 119]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-120" id="page-120" href="#page-120" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
The CAPWAP protocol allows an AC to configure a static IP address on
|
|
a WTP using the WTP Static IP Address Information message element.
|
|
This message element SHOULD NOT be used in NAT'ed environments,
|
|
unless the administrator is familiar with the internal IP addressing
|
|
scheme within the WTP's private network, and does not rely on the
|
|
public address seen by the AC.
|
|
|
|
When a WTP detects the duplicate address condition, it generates a
|
|
message to the AC, which includes the Duplicate IP Address message
|
|
element. The IP Address embedded within this message element is
|
|
different from the public IP address seen by the AC.
|
|
|
|
When CAPWAP is run over IPv6, NAT support can only be provided if the
|
|
IPv6 NAT system is capable of performing address translation over the
|
|
UDP-Lite 3828 protocol [<a href="#ref-11" title=""The Lightweight User Datagram Protocol (UDP-Lite)"">11</a>]. A protocol interoperability issues will
|
|
exist if the NAT system is being utilized for IPv4/IPv6 address
|
|
translation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 120]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-121" id="page-121" href="#page-121" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-12" href="#section-12">12</a>. Security Considerations</span>
|
|
|
|
This section describes security considerations for the CAPWAP
|
|
protocol. It also provides security recommendations for protocols
|
|
used in conjunction with CAPWAP.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.1" href="#section-12.1">12.1</a>. CAPWAP Security</span>
|
|
|
|
As it is currently specified, the CAPWAP protocol sits between the
|
|
security mechanisms specified by the wireless link layer protocol
|
|
(e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust
|
|
between the STA and WTP using a series of preestablished trust
|
|
relationships:
|
|
|
|
|
|
STA WTP AC AAA
|
|
==============================================
|
|
|
|
DTLS Cred AAA Cred
|
|
<------------><------------->
|
|
|
|
EAP Credential
|
|
<------------------------------------------>
|
|
|
|
wireless link layer
|
|
(e.g.802.11 PTK)
|
|
<--------------> or
|
|
<--------------------------->
|
|
(derived)
|
|
|
|
Within CAPWAP, DTLS is used to secure the link between the WTP and
|
|
AC. In addition to securing control messages, it's also a link in
|
|
this chain of trust for establishing link layer keys. Consequently,
|
|
much rests on the security of DTLS.
|
|
|
|
In some CAPWAP deployment scenarios, there are two channels between
|
|
the WTP and AC: the control channel, carrying CAPWAP control
|
|
messages, and the data channel, over which client data packets are
|
|
tunneled between the AC and WTP. Typically, the control channel is
|
|
secured by DTLS, while the data channel is not.
|
|
|
|
The use of parallel protected and unprotected channels deserves
|
|
special consideration, but does not create a threat. There are two
|
|
potential concerns: attempting to convert protected data into un-
|
|
protected data and attempting to convert un-protected data into
|
|
protected data. These concerns are addressed below.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 121]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-122" id="page-122" href="#page-122" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" name="section-12.1.1" href="#section-12.1.1">12.1.1</a>. Converting Protected Data into Unprotected Data</span>
|
|
|
|
Since CAPWAP does not support authentication-only ciphers (i.e. all
|
|
supported ciphersuites include encryption and authentication), it is
|
|
not possible to convert protected data into unprotected data. Since
|
|
encrypted data is (ideally) indistinguishable from random data, the
|
|
probability of an encrypted packet passing for a well-formed packet
|
|
is effectively zero.
|
|
|
|
<span class="h4"><a class="selflink" name="section-12.1.2" href="#section-12.1.2">12.1.2</a>. Converting Unprotected Data into Protected Data (Insertion)</span>
|
|
|
|
The use of message authentication makes it impossible for the
|
|
attacker to forge protected records. This makes conversion of
|
|
unprotected records to protected records impossible.
|
|
|
|
<span class="h4"><a class="selflink" name="section-12.1.3" href="#section-12.1.3">12.1.3</a>. Deletion of Protected Records</span>
|
|
|
|
An attacker could remove protected records from the stream, though
|
|
not undetectably so, due the built-in reliability of the underlying
|
|
CAPWAP protocol. In the worst case, the attacker would remove the
|
|
same record repeatedly, resulting in a CAPWAP session timeout and
|
|
restart. This is effectively a DoS attack, and could be accomplished
|
|
by a man in the middle regardless of the CAPWAP protocol security
|
|
mechanisms chosen.
|
|
|
|
<span class="h4"><a class="selflink" name="section-12.1.4" href="#section-12.1.4">12.1.4</a>. Insertion of Unprotected Records</span>
|
|
|
|
An attacker could inject packets into the unprotected channel, but
|
|
this may become evident if sequence number desynchronization occurs
|
|
as a result. Only if the attacker is a MiM can packets be inserted
|
|
undetectably. This is a consequence of that channel's lack of
|
|
protection, and not a new threat resulting from the CAPWAP security
|
|
mechanism.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.2" href="#section-12.2">12.2</a>. Session ID Security</span>
|
|
|
|
Since DTLS does not export a unique session identifier, there can be
|
|
no explicit protocol binding between the DTLS layer and CAPWAP layer.
|
|
As a result, implementations MUST provide a mechanism for performing
|
|
this binding. For example, an AC MUST NOT associate decrypted DTLS
|
|
control packets with a particular WTP session based solely on the
|
|
Session ID in the packet header. Instead, identification should be
|
|
done based on which DTLS session decrypted the packet. Otherwise one
|
|
authenticated WTP could spoof another authenticated WTP by altering
|
|
the Session ID in the encrypted CAPWAP header.
|
|
|
|
It should be noted that when the CAPWAP data channel is unencrypted,
|
|
the WTP Session ID is exposed and possibly known to adversaries and
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 122]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-123" id="page-123" href="#page-123" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
other WTPs. This would allow the forgery of the source of data-
|
|
channel traffic. This, however, should not be a surprise for
|
|
unencrypted data channels. When the data channel is encrypted, the
|
|
Session ID is not exposed, and therefore can safely be used to
|
|
associate a data and control channel. The 64-bit length of the
|
|
Session ID mitigates online guessing attacks where an adversarial,
|
|
authenticated WTP tries to correlate his own data channel with
|
|
another WTP's control channel. Note that for encrypted data
|
|
channels, the Session ID should only be used for correlation for the
|
|
first packet immediately after the initial DTLS handshake. Future
|
|
correlation should instead be done via identification of a packet's
|
|
DTLS session.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.3" href="#section-12.3">12.3</a>. Discovery Attacks</span>
|
|
|
|
Since the Discovery Request messages are sent in the clear, it is
|
|
important that AC implementations NOT assume that receiving such a
|
|
request from a WTP implies that it has rebooted, and consequently
|
|
tear down any active DTLS sessions. Discovery Request messages can
|
|
easily be spoofed by malicious devices, so it is important that the
|
|
AC maintain two separate sets of states for the WTP until the
|
|
DTLSSessionEstablished notification is received, indicating that the
|
|
WTP was authenticated. Once a new DTLS session is successfully
|
|
established, any state referring to the old session can be cleared.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.4" href="#section-12.4">12.4</a>. Interference with a DTLS Session</span>
|
|
|
|
If a WTP or AC repeatedly receives packets which fail DTLS
|
|
authentication or decryption, this could indicate a DTLS
|
|
desynchronization between the AC and WTP, a link prone to
|
|
undetectable bit errors, or an attacker trying to disrupt a DTLS
|
|
session.
|
|
|
|
In the state machine (<a href="#section-2.3">section 2.3</a>), transitions to the DTLS tear down
|
|
state can be triggered by frequently receiving DTLS packets with
|
|
authentication or decryption errors. The threshold or technique for
|
|
deciding when to move to the tear down state should be chosen
|
|
carefully. Being able to easily transition to DTLS TD allows easy
|
|
detection of malfunctioning devices, but allows for denial of service
|
|
attacks. Making it difficult to transition to DTLS TD prevents
|
|
denial of service attacks, but makes it more difficult to detect and
|
|
reset a malfunctioning session. Implementers should set this policy
|
|
with care.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.5" href="#section-12.5">12.5</a>. Use of Preshared Keys in CAPWAP</span>
|
|
|
|
While use of preshared keys may provide deployment and provisioning
|
|
advantages not found in public key based deployments, it also
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 123]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-124" id="page-124" href="#page-124" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
introduces a number of operational and security concerns. In
|
|
particular, because the keys must typically be entered manually, it
|
|
is common for people to base them on memorable words or phrases.
|
|
These are referred to as "low entropy passwords/passphrases".
|
|
|
|
Use of low-entropy preshared keys, coupled with the fact that the
|
|
keys are often not frequently updated, tends to significantly
|
|
increase exposure. For these reasons, the following recommendations
|
|
are made:
|
|
|
|
o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP
|
|
SHOULD have a unique PSK. Since WTPs will likely be widely
|
|
deployed, their physical security is not guaranteed. If PSKs are
|
|
not unique for each WTP, key reuse would allow the compromise of
|
|
one WTP to result in the compromise of others
|
|
|
|
o Generating PSKs from low entropy passwords is NOT RECOMMENDED.
|
|
|
|
o It is RECOMMENDED that implementations that allow the
|
|
administrator to manually configure the PSK also provide a
|
|
capability for generation of new random PSKs, taking <a href="./rfc4086">RFC 4086</a> [<a href="#ref-2" title=""Randomness Requirements for Security"">2</a>]
|
|
into account.
|
|
|
|
o Preshared keys SHOULD be periodically updated. Implementations
|
|
MAY facilitate this by providing an administrative interface for
|
|
automatic key generation and periodic update, or it MAY be
|
|
accomplished manually instead.
|
|
|
|
Every pairwise combination of WTP and AC on the network SHOULD have a
|
|
unqiue PSK. This prevents the domino effect (see Guidance for AAA
|
|
Key Management [<a href="#ref-16" title=""Guidance for AAA Key Management"">16</a>]). If PSKs are tied to specific WTPs, then
|
|
knowledge of the PSK implies a binding to a specified identity that
|
|
can be authorized.
|
|
|
|
If PSKs are shared, this binding between device and identity is no
|
|
longer possible. Compromise of one WTP can yield compromise of
|
|
another WTP, violating the CAPWAP security hierarchy. Consequently,
|
|
sharing keys between WTPs is NOT RECOMMENDED.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.6" href="#section-12.6">12.6</a>. Use of Certificates in CAPWAP</span>
|
|
|
|
For public-key-based DTLS deployments, each device SHOULD have unique
|
|
credentials, with an extended key usage authorizing the device to act
|
|
as either a WTP or AC. If devices do not have unique credentials, it
|
|
is possible that by compromising one device, any other device using
|
|
the same credential may also be considered to be compromised.
|
|
|
|
Certificate validation involves checking a large variety of things.
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 124]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-125" id="page-125" href="#page-125" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Since the necessary things to validate are often environment-
|
|
specific, many are beyond the scope of this document. In this
|
|
section, we provide some basic guidance on certificate validation.
|
|
|
|
Each device is responsible for authenticating and authorizing devices
|
|
with which they communicate. Authentication entails validation of
|
|
the chain of trust leading to the peer certificate, followed by the
|
|
the peer certificate itself. At a minimum, devices SHOULD use SSH-
|
|
style certificate caching to guarantee consistency. If devices have
|
|
access to a certificate authority, they SHOULD properly validate the
|
|
trust chain. Implementations SHOULD also provide a secure method for
|
|
verifying that the credential in question has not been revoked.
|
|
|
|
Note that if the WTP relies on the AC for network connectivity (e.g.
|
|
the AC is a layer 2 switch to which the WTP is directly connected),
|
|
the WTP may not be able to contact an OCSP server or otherwise obtain
|
|
an up to date CRL if a compromised AC doesn't explicitly permit this.
|
|
This cannot be avoided, except through effective physical security
|
|
and monitoring measures at the AC.
|
|
|
|
Proper validation of certificates typically requires checking to
|
|
ensure the certificate has not yet expired. If devices have a real-
|
|
time clock, they SHOULD verify the certificate validity dates. If no
|
|
real-time clock is available, the device SHOULD make a best-effort
|
|
attempt to validate the certificate validity dates through other
|
|
means. Failure to check a certificate's temporal validity can make a
|
|
device vulnerable to man-in-the-middle attacks launched using
|
|
compromised, expired certificates, and therefore devices should make
|
|
every effort to perform this validation.
|
|
|
|
<span class="h3"><a class="selflink" name="section-12.7" href="#section-12.7">12.7</a>. AAA Security</span>
|
|
|
|
The AAA protocol is used to distribute EAP keys to the ACs, and
|
|
consequently its security is important to the overall system
|
|
security. When used with TLS or IPsec, security guidelines specified
|
|
in <a href="./rfc3539">RFC 3539</a> [<a href="#ref-5" title=""Authentication, Authorization and Accounting (AAA) Transport Profile"">5</a>] SHOULD be followed.
|
|
|
|
In general, the link between the AC and AAA server SHOULD be secured
|
|
using a strong ciphersuite keyed with mutually authenticated session
|
|
keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared
|
|
secret authentication as it is often vulnerable to dictionary
|
|
attacks, but rather SHOULD use stronger underlying security
|
|
mechanisms.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 125]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-126" id="page-126" href="#page-126" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-13" href="#section-13">13</a>. Management Considerations</span>
|
|
|
|
The CAPWAP protocol assumes that it is the only configuration
|
|
interface to the WTP to configure parameters that are specified in
|
|
the CAPWAP specifications. While the use of a separate management
|
|
protocol MAY be used for the purposes of monitoring the WTP directly,
|
|
configuring the WTP through a separate management interface is not
|
|
recommended. Configuring the WTP through a separate protocol, such
|
|
as via a CLI or SNMP, could lead to the AC state being out of sync
|
|
with the WTP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 126]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-127" id="page-127" href="#page-127" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-14" href="#section-14">14</a>. IANA Considerations</span>
|
|
|
|
A separate UDP port for data channel communications is (currently)
|
|
the selected demultiplexing mechanism, and a port must be assigned
|
|
for this purpose in <a href="#section-3.1">Section 3.1</a>. The UDP port numbers are listed by
|
|
IANA at <a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>.
|
|
|
|
IANA needs to assign an organization local multicast address called
|
|
the "All ACs multicast address" from the IPv6 multicast address
|
|
registry in <a href="#section-3.3">Section 3.3</a>
|
|
|
|
<span class="h3"><a class="selflink" name="section-14.1" href="#section-14.1">14.1</a>. CAPWAP Message Types</span>
|
|
|
|
The Message Type field in the CAPWAP header (<a href="#section-4.5.1.1">Section 4.5.1.1</a>) is used
|
|
to identify the operation performed by the message. There are
|
|
multiple namespaces, which is identified via the first three octets
|
|
of the field containing the IANA Enterprise Number [<a href="#ref-10" title=""Guidelines for Writing an IANA Considerations Section in RFCs"">10</a>]. When the
|
|
Enterprise Number is set to zero, the message types are reserved for
|
|
use by the base CAPWAP specification which are controlled and
|
|
maintained by IANA and requires a Standards Action.
|
|
|
|
<span class="h3"><a class="selflink" name="section-14.2" href="#section-14.2">14.2</a>. Wireless Binding Identifiers</span>
|
|
|
|
The Wireless Binding Identifier (WBID) field in the CAPWAP header
|
|
(<a href="#section-4.3">Section 4.3</a>) is used to identify the wireless technology associated
|
|
with the packet. Due to the limited address space available, a new
|
|
WBID request requires Standards Action.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 127]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-128" id="page-128" href="#page-128" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-15" href="#section-15">15</a>. Acknowledgements</span>
|
|
|
|
The following individuals are acknowledged for their contributions to
|
|
this protocol specification: Puneet Agarwal, Saravanan Govindan,
|
|
Peter Nilsson, and David Perkins.
|
|
|
|
Michael Vakulenko contributed text to describe how CAPWAP can be used
|
|
over layer 3 (IP/UDP) networks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 128]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-129" id="page-129" href="#page-129" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" name="section-16" href="#section-16">16</a>. References</span>
|
|
|
|
<span class="h3"><a class="selflink" name="section-16.1" href="#section-16.1">16.1</a>. Normative References</span>
|
|
|
|
[<a name="ref-1" id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
|
Levels", <a href="./bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
|
|
|
|
[<a name="ref-2" id="ref-2">2</a>] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
|
|
Requirements for Security", <a href="./bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>, June 2005.
|
|
|
|
[<a name="ref-3" id="ref-3">3</a>] Mills, D., "Network Time Protocol (Version 3) Specification,
|
|
Implementation", <a href="./rfc1305">RFC 1305</a>, March 1992.
|
|
|
|
[<a name="ref-4" id="ref-4">4</a>] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
|
|
Public Key Infrastructure Certificate and Certificate
|
|
Revocation List (CRL) Profile", <a href="./rfc3280">RFC 3280</a>, April 2002.
|
|
|
|
[<a name="ref-5" id="ref-5">5</a>] Aboba, B. and J. Wood, "Authentication, Authorization and
|
|
Accounting (AAA) Transport Profile", <a href="./rfc3539">RFC 3539</a>, June 2003.
|
|
|
|
[<a name="ref-6" id="ref-6">6</a>] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
|
|
Transport Layer Security (TLS)", <a href="./rfc4279">RFC 4279</a>, December 2005.
|
|
|
|
[<a name="ref-7" id="ref-7">7</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
|
|
Protocol Version 1.1", <a href="./rfc4346">RFC 4346</a>, April 2006.
|
|
|
|
[<a name="ref-8" id="ref-8">8</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
|
|
Security", <a href="./rfc4347">RFC 4347</a>, April 2006.
|
|
|
|
[<a name="ref-9" id="ref-9">9</a>] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
|
|
Extensions", <a href="./rfc2132">RFC 2132</a>, March 1997.
|
|
|
|
[<a name="ref-10" id="ref-10">10</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
|
|
Considerations Section in RFCs", <a href="./bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>,
|
|
October 1998.
|
|
|
|
[<a name="ref-11" id="ref-11">11</a>] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
|
|
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
|
|
<a href="./rfc3828">RFC 3828</a>, July 2004.
|
|
|
|
[<a name="ref-12" id="ref-12">12</a>] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol
|
|
Binding for IEEE 802.11", <a href="./draft-ietf-capwap-protocol-binding-ieee80211-04">draft-ietf-capwap-protocol-</a>
|
|
<a href="./draft-ietf-capwap-protocol-binding-ieee80211-04">binding-ieee80211-04</a> (work in progress), June 2007.
|
|
|
|
[<a name="ref-13" id="ref-13">13</a>] Calhoun, P., "CAPWAP Access Controller DHCP Option",
|
|
<a href="./draft-ietf-capwap-dhc-ac-option-00">draft-ietf-capwap-dhc-ac-option-00</a> (work in progress),
|
|
June 2007.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 129]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-130" id="page-130" href="#page-130" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" name="section-16.2" href="#section-16.2">16.2</a>. Informational References</span>
|
|
|
|
[<a name="ref-14" id="ref-14">14</a>] Reynolds, J., "Assigned Numbers: <a href="./rfc1700">RFC 1700</a> is Replaced by an On-
|
|
line Database", <a href="./rfc3232">RFC 3232</a>, January 2002.
|
|
|
|
[<a name="ref-15" id="ref-15">15</a>] Manner, J. and M. Kojo, "Mobility Related Terminology",
|
|
<a href="./rfc3753">RFC 3753</a>, June 2004.
|
|
|
|
[<a name="ref-16" id="ref-16">16</a>] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
|
|
<a href="./draft-housley-aaa-key-mgmt-09">draft-housley-aaa-key-mgmt-09</a> (work in progress),
|
|
February 2007.
|
|
|
|
[<a name="ref-17" id="ref-17">17</a>] Modadugu et al, N., "The Design and Implementation of Datagram
|
|
TLS", Feb 2004.
|
|
|
|
[<a name="ref-18" id="ref-18">18</a>] IEEE, "Guidelines for use of a 48-bit Extended Unique
|
|
Identifier", Dec 2005.
|
|
|
|
[<a name="ref-19" id="ref-19">19</a>] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
|
|
REGISTRATION AUTHORITY".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 130]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-131" id="page-131" href="#page-131" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Editors' Addresses
|
|
|
|
Pat R. Calhoun
|
|
Cisco Systems, Inc.
|
|
170 West Tasman Drive
|
|
San Jose, CA 95134
|
|
|
|
Phone: +1 408-853-5269
|
|
Email: pcalhoun@cisco.com
|
|
|
|
|
|
Michael P. Montemurro
|
|
Research In Motion
|
|
5090 Commerce Blvd
|
|
Mississauga, ON L4W 5M4
|
|
Canada
|
|
|
|
Phone: +1 905-629-4746 x4999
|
|
Email: mmontemurro@rim.com
|
|
|
|
|
|
Dorothy Stanley
|
|
Aruba Networks
|
|
1322 Crossman Ave
|
|
Sunnyvale, CA 94089
|
|
|
|
Phone: +1 630-363-1389
|
|
Email: dstanley@arubanetworks.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Calhoun, Editor, et al. Expires December 13, 2007 [Page 131]</span>
|
|
</pre><!--NewPage--><pre class='newpage'><a name="page-132" id="page-132" href="#page-132" class="invisible"> </a>
|
|
<span class="grey">Internet-Draft CAPWAP Protocol Specification June 2007</span>
|
|
|
|
|
|
Full Copyright Statement
|
|
|
|
Copyright (C) The IETF Trust (2007).
|
|
|
|
This document is subject to the rights, licenses and restrictions
|
|
contained in <a href="./bcp78">BCP 78</a>, and except as set forth therein, the authors
|
|
retain all their rights.
|
|
|
|
This document and the information contained herein are provided on an
|
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
|
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
|
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
|
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
Intellectual Property
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
Intellectual Property Rights or other rights that might be claimed to
|
|
pertain to the implementation or use of the technology described in
|
|
this document or the extent to which any license under such rights
|
|
might or might not be available; nor does it represent that it has
|
|
made any independent effort to identify any such rights. Information
|
|
on the procedures with respect to rights in RFC documents can be
|
|
found in <a href="./bcp78">BCP 78</a> and <a href="./bcp79">BCP 79</a>.
|
|
|
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|
assurances of licenses to be made available, or the result of an
|
|
attempt made to obtain a general license or permission for the use of
|
|
such proprietary rights by implementers or users of this
|
|
specification can be obtained from the IETF on-line IPR repository at
|
|
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
copyrights, patents or patent applications, or other proprietary
|
|
rights that may cover technology that may be required to implement
|
|
this standard. Please address the information to the IETF at
|
|
ietf-ipr@ietf.org.
|
|
|
|
|
|
Acknowledgment
|
|
|
|
Funding for the RFC Editor function is provided by the IETF
|
|
Administrative Support Activity (IASA).
|
|
|
|
|
|
|
|
|
|
|
|
Calhoun, Editor, et al. Expires December 13, 2007 [Page 132]
|
|
|
|
</pre><br />
|
|
<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.111, available from
|
|
<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a>
|
|
</small></small></span>
|
|
</body></html>
|