to innovate in several ways even while using a local-MAC
architecture. For example, functions such as mobility, flexible user
data encryption options, and fast handoffs can be enabled through
tunneling of user data back to an AC, or as LWAPP defines, a data
termination endpoint, which could be different from the AC. In
addition, there are special QoS or application-aware treatments of
user data packets such as voice or video. Improved transparency and
compatibility with future wireless technologies are also possible
when encapsulating user data in a common format, such as 802.3,
between the access point and the AC or other termination point in the
network.
Another possibility is when a native wireless MAC changes in the
future, if a new WTP that supports this MAC change can also support a
wireless MAC -> 802.3 integration function, then the wireless MAC
layer change may remain transparent to an AC and still maintain many
of the benefits that data tunneling can bring.
LWAPP does support a header for tunneled user data that contains
layer 1 wireless information (Received Signal Strength Indication
(RSSI) and Signal-to-Noise Ratio (SNR)) that is independent of the
wireless layer 2 MAC. Innovations related to the use of RSSI and SNR
at the AC may be retained even when tunneling 802.3 user data across
different wireless MACs.
It is likely that many other features could be created by innovative
implementers using this method. However, LWAPP narrowly defines the
local-MAC architecture to exclude an option of tunneling data frames
back to the AC. Given the broad support for tunneling 802.3 data
frames between the WTP and AC across all the proposals and existing
proprietary industry implementations, the evaluation team strongly
recommends that the working group consider a data tunneling mode for
local-MAC be added to the LWAPP proposal and become part of the
standard CAPWAP protocol.
9.1.3.2. Mandatory and Optional Tunneling Modes
If more than one tunneling mode is part of the CAPWAP protocol, the
evaluation team recommends that the working group choose one method
as mandatory and other methods as optional. In addition, the CAPWAP
protocol must implement the ability to negotiate which tunneling
methods are supported through a capabilities exchange. This allows
ACs and WTPs freedom to implement a variety of modes but always have
the option of falling back to a common mode.
The choice of which mode(s) should be mandatory is an important
decision and may impact many decisions implementers have to make with
their hardware and software choices for both WTPs and ACs. The
evaluation team believes that the working group should address this
issue of local-MAC data tunneling and carefully choose which mode(s)
should be mandatory.
9.2. Additional Recommendations Relevant to Desirable Objectives
9.2.1. Access Control
Abstraction of STA access control, such as that implemented in CTP
and WiCoP, stands out as a valuable feature as it is fundamental to
the operational capabilities of many types of wireless networks, not
just 802.11. LWAPP implements station access control as an 802.11-
specific function via forwarding of 802.11 control frames to the
access controller. LWAPP has abstracted the STA Delete function out
of the 802.11 binding. However, the Add STA function is part of the
802.11 binding. It would be useful to implement the wireless MAC
independent functions for adding a STA outside of the 802.11 binding.
9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling
LWAPP currently specifies layer 2 and layer 3 methods for data
tunneling. The evaluation team believes that the layer 2 method is
redundant to the layer 3 method. The team recommends that the layer
2 method encapsulation be removed from the LWAPP protocol.
9.2.3. Data Encapsulation Standard
LWAPP’s layer 3 data encapsulation meets the working group
objectives. However, the evaluation team recommends the use of a
standards-based protocol for encapsulation of user data between the
WTP and AC. GRE or Layer 2 Tunneling Protocol (L2TP) could make good
candidates as standards-based encapsulation protocols for data
tunneling.
Using a standard gives the opportunity for code reuse, whether it is
off-the-shelf microcode for processors, code modules that can be
purchased for real-time operating systems, or open-source
implementations for Unix-based systems. In addition, L2TP and GRE
are designed to encapsulate multiple data types, increasing
flexibility for supporting future wireless technologies.
10. Normative References
[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC)
Security Enhancements", July 2004.
[ARCH] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005.
[OBJ] Govindan, S., Ed., Cheng, H., Yao, ZH., Zhou, WH., and L.
Yang, "Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
11. Informative References
[CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes,
"CAPWAP Tunneling Protocol (CTP)", Work in Progress, April
2005.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[LWAPP] Calhoun, P., O’Hara, B., Kelly, S., Suri, R., Williams,
M., Hares, S., and N. Cam Winget, "Light Weight Access
Point Protocol (LWAPP)", Work in Progress, March 2005.
[RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil,
B., Stevens, M., and B. Wolff, "Authentication,
Authorization, and Accounting: Protocol Evaluation", RFC
3127, June 2001.
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP :
Secure Light Access Point Protocol", Work in Progress, May
2005.
[WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
"Wireless LAN Control Protocol (WiCoP)", Work in Progress,
March 2005.
Authors’ Addresses
Darren P. Loher
Envysion, Inc.
2010 S. 8th Street
Boulder, CO 80302
USA
Phone: +1.303.667.8761
EMail: dplore@gmail.com
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Anover, MA 01810-1008
USA
Phone: +1.978.684.1330
EMail: dnelson@enterasys.com
Oleg Volinsky
Colubris Networks, Inc.
200 West Street
Waltham, MA 02451
USA
Phone: +1.781.547.0329
EMail: ovolinsky@colubris.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
USA
Phone: +1.972.509.5599
EMail: sarikaya@ieee.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, 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 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 BCP 78 and BCP 79.
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
http://www.ietf.org/ipr.
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).