Technical Summary
The CAPWAP problem statement (RFC 3990) describes a problem that
needs to be addressed before a wireless LAN (WLAN) network designer
can construct a solution composed of Wireless Termination Points
(WTP) and Access Controllers (AC) from multiple, different vendors.
One of the primary goals is to find a solution that solves the
interoperability between the two classes of devices (WTPs and ACs)
which then enables an AC from one vendor to control and manage a WTP
from another.
The interoperability problem is more general than as stated in the
CAPWAP problem statement because it can arise out of other
networks that do not necessarily involve WLAN or any wireless
devices. A similar problem exists in any network that is composed of
network elements that are managed by a centralized controller where
these two classes of devices are from different vendors and need to
interoperate with each other such that the network elements can be
controlled and managed by the controller.
A possible solution to this problem is to split it into two parts -
one that is technology or application independent which serves as a
common framework across multiple underlying technologies, and another
that is dependent on the underlying technology that is being used in
the network. For example, methods and parameters used by an 802.11
AC to configure and manage a network of 802.11 WTPs are expected to
be quite different than that used by an equivalent 802.16 controller
to manage a network of 802.16 base stations. The architectural
choices for these two underlying technologies may also be
significantly different.
This document defines a protocol that forms the common
technology-independent framework and the ability to negotiate and
add, on top of this framework, a control protocol that contains a
technology-dependent component to arrive at a complete solution. It
also defines two such control protocols - an 802.11 Control
protocol, and another a more generic image download protocol, in this
draft.
Even though the text in this document is written to specifically
address the problem stated in RFC 3990, the solution can be applied
to any problem that has a controller (equivalent to the AC) managing
one or more network elements (equivalent to the WTP).
Working Group Summary
This document was a candidate protocol submission for the Control and
Provisioning of Wireless Access Points (CAPWAP) Working Group. It is
being published for informational and historical reference purposes.
Protocol Quality
The evaluation of the candidate protocols for CAPWAP is being
described in RFC 4565.
This document is not a candidate for any level of Internet
Standard. The document has not had complete IETF review for such
things as security, congestion control, or inappropriate interaction
with deployed protocols.
Note to RFC Editor
The IESG takes note that this submission is being published for
historic reference, with the intention to document an initial
submission for the CAPWAP protocol. In order to avoid confusion, the
IESG recommends that this document be published only after the
approval and publication of the CAPWAP protocol (draft-ietf-capwap-
protocol-specification) as Proposed Standard.
The IESG believes that the appropriate status at the publication of
this RFC would be 'Historic', and that the note 'Obsoleted by RFC
xxxx' should be added on the front page, where xxxx will be the RFC
number of the CAPWAP protocol specification.
RFC Editor, please make the following changes:
1. Place either in or immediately following the "Status of this Memo"
section of the finished RFC the IESG note below
2. Add the note 'Obsoleted by RFC xxxx' on the front page, where xxxx
will be the RFC number of the CAPWAP protocol specification.
3. Update the boilerplate according to RFC 4748
4. Rename 'References' Section as 'Informative References'
5. Replace outdated reference draft-ietf-capwap-objectives by RFC 4564
6. Replace outdated reference draft-rescorla-dtls by RFC 4347
7. Replace obsolete reference: RFC 2246 by RFC 4346
IESG Note
In conformance with RFC 3932, Section 4, the IESG requests the
publication of the following note:
"This RFC documents the SLAPP protocol as it was when submitted to
the IETF as a basis for further work in the CAPWAP WG, and therefore
it may resemble the CAPWAP protocol specification (RFC XXXX), as well
as other current IETF work in progress or published IETF work.
This RFC is being published solely for the historical record. The
protocol described in this RFC has not been thoroughly reviewed and may
contain errors and omissions.
RFC XXXX documents the standards track solution for the CAPWAP
Working Group and obsoletes any and all mechanisms defined in this RFC.
This RFC itself is not a candidate for any level of Internet
Standard and should not be used as a basis for any sort of deployment
in the Internet.
The IETF disclaims any knowledge of the fitness of this
RFC for any purpose, and in particular notes that it has not had
complete IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion."
IANA Note
As this document is not a candidate for standardization or deployment
in the Internet, IANA is not required to take any action.