idnits 2.17.1 draft-zhou-capwap-objectives-00.txt: -(168): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2004) is 7100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 192 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAPWAP Working Group Wenhui Zhou 2 Internet Draft China Mobile Communication Corporation 3 Zhonghui Yao 4 Document: Objectives for Control and Huawei Technologies 5 Provisioning of Wireless Access Points Lily Yang 6 Intel Corp. 7 Meimei Dang 8 Research Institute of Telecommunication Transmission 9 Dong Wang 10 ZTE 11 Expires: April 2005 November 2004 13 Objectives for Control and Provisioning of Wireless Access Points 14 (CAPWAP) Protocol 15 draft-zhou-capwap-objectives-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire in April 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 50 This document presents a set of objectives or requirements for the 51 Control and Provisioning of Wireless Access Points (CAPWAP) protocol. 52 It presents the requirements from different aspects including 53 architecture, user (client) access, service, control, management and 54 security. 56 1. Definitions 58 1.1 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119. 64 1.2 Terminology Used in this Document 66 CAPWAP - Control and Provisioning of Wireless Access Points. 68 CAPWAP Functions - a set of WLAN control functions that are not 69 directly defined by IEEE 802.11 Standards, but deemed essential 70 for effective control, configuration and management of 802.11 WLAN 71 access networks. 73 Wireless Termination Point (WTP) - the physical or network entity 74 that contains RF antenna and 802.11 PHY to transmit and receive 75 station traffics for the IEEE 802.11 WLAN access networks. Such 76 physical entities are often called "Access Points" (AP) previously, 77 but "AP" can also be used to refer to logical entity that 78 implements 802.11services. So we recommend using "WTP" instead to 79 explicitly refer to the physical entity. 81 Centralized WLAN Architecture - the WLAN access network 82 architecture family in which the logical functions, including both 83 IEEE 802.11 and CAPWAP functions (wherever applicable), are 84 implemented across a hierarchy of network entities. At the low 85 level of such hierarchy are the WTPs while at the higher level are 86 the Access Controllers(ACs), which are responsible to control, 87 configure and manage the entire WLAN access networks. 89 Access Controller (AC) - The network entity in the Centralized WLAN 90 architectures that provide WTPs access to the centralized 91 hierarchical network infrastructure, either in the data plane, 92 control plane, or management plane, or a combination therein. 94 Local MAC Architecture - A sub-group of the Centralized WLAN 95 Architecture, where the majority or entire set of 802.11 MAC 96 functions (including most of the 802.11 management frame 97 processing) are implemented at the WTP. Therefore, the 802.11 MAC 98 stays intact and local in the WTP, along with PHY. 100 Split MAC Architecture - A sub-group of the Centralized WLAN 101 Architecture, with the characteristic that WTPs in such WLAN 102 access networks only implement the delay sensitive MAC services 103 (including all control frames and some management frames) for IEEE 104 802.11, while tunneling all the remaining management and data 105 frames to AC for centralized processing.The IEEE 802.11 MAC as 106 defined by IEEE 802.11 Standards is effectively split between the 107 WTP and AC. 109 2. Introduction 111 As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale 112 deployment of WLAN networks is highlighting certain technical 113 challenges including management, monitoring and control of large 114 number of Access Points (APs). Distributing and maintaining a 115 consistent configuration throughout the entire set of APs in the WLAN 116 is a difficult task. The shared and dynamic nature of the wireless 117 medium also demands effective coordination among the APs to minimize 118 radio interference and maximize network performance. Furthermore, 119 vendors implement not only the services defined in the IEEE 802.11 120 standard, but also a variety of value-added services or functions, 121 like load balancing support, QoS, station mobility support, rogue AP 122 detection, etc. 124 The Centralized WLAN Architecture family, as described in [2], is 125 an innovative architectural solution intended to address the 126 aforementioned problems. Two classes of the Centralized WLAN 127 Architecture family, namely the Local MAC and the Split MAC, will be 128 supported by the CAPWAP protocol to realize interoperability of the 129 AC-WTP interface among vendors. This document puts forth the 130 requirements for CAPWAP protocol between the AC and WTP. 132 2.1 Centralized WLAN Architecture 134 Figure 1 shows a diagram of the Centralized WLAN Architecture from 135 [2]. In the Centralized WLAN Architecture, there is one or more 136 centralized controllers for managing a large number of WTP devices. 137 The centralized controller is commonly referred to as an Access 138 Controller (AC), whose main function is to manage, control and 139 configure the WTP devices that are present in the network. In 140 addition to being a centralized entity for the control and management 141 plane, it may also become a natural aggregation point for the data 142 plane, since it is typically situated in a centralized location in 143 the wireless access network. The AC is often co-located with an L2 144 bridge, a switch, or an L3 router, and hence may be referred to as 145 Access Bridge, or Access Router in those particular cases. Therefore, 146 an Access Controller could be either an L3 or L2 device, and Access 147 Controller is the generic terminology we use throughout this document. 149 It is also possible that multiple ACs are present in a network for 150 purposes of redundancy, load balancing, etc. This architecture 151 family has several distinct characteristics that are worth noting. 152 First of all, the hierarchical architecture and the centralized AC 153 afford much better manageability for the large scale networks. 154 Secondly, since the IEEE 802.11 functions and the CAPWAP control 155 functions are provided by the WTP devices and the AC together, the 156 WTP devices themselves may not implement the full 802.11 functions as 157 defined in the standards any more. Therefore, it can be said that the 158 full 802.11 functions are implemented across multiple physical 159 network devices, namely, the WTPs and ACs. Since the WTP devices 160 only implement a portion of the functions that standalone APs 161 implement, WTP devices in this architecture are sometimes referred to 162 as light weight or thin APs by some vendors. 164 As shown in Figure 1, CAPWAP protocol is the protocol between WTP and 165 AC that will provide vendor interoperability when it is standardized. 166 This protocol may run on different interconnection technology. 168 ����+----------------+ +---------------+ +---------------+ 169 | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | 170 | ... | | ... | | ... | 171 | +-------+ | | +-------+ | | +-------+ | 172 +----| WTP |--+ +----| WTP |--+ +----| WTP |--+ 173 +---+---+ +---+---+ +---+---+ 174 | | | 175 +------------------+ | +-----------------+ 176 | |...| 177 +----+--+---+--------+ 178 | CAPWAP Protocol | 179 +----+--+---+--------+ 180 | 181 | 182 +-----+----+ 183 | AC | 184 +----------+ 186 Figure 1: Centralized WLAN Architecture Diagram 188 2.2 Local MAC 190 The main motivation of Local MAC architecture model is to offload 191 network access policies and management functions (CAPWAP functions 192 described in [2]) to the AC, without splitting the 802.11 MAC 193 functionality between WTPs and AC. The whole 802.11 MAC resides on 194 the WTPs locally, including all the 802.11 management and control 195 frame processing for the STAs; on the other hand, information related 196 to management and configuration of the WTP devices is communicated 197 with a centralized AC, to facilitate management of the network, and 198 maintain a consistent network-wide configuration for the WTP devices. 200 2.3 Split MAC 202 The main idea behind the Split MAC architecture is to implement part 203 of the 802.11 MAC functionality on a centralized AC instead of the 204 WTPs, in addition to the services required for managing and 205 monitoring the WTP devices. Usually, the decision of which functions 206 of the 802.11 MAC need to be provided by the AC is based on the time- 207 criticality of the services considered. 209 In the Split MAC architecture, the WTP terminates the 210 infrastructure side of the wireless physical link, provides radio- 211 related management, and also implements all time-critical 213 functionality of the 802.11 MAC. In addition, the non real-time 214 management functions are handled by a centralized AC, along with 215 higher-level services, such as configuration, QoS, policies for load- 216 balancing, access control lists, etc. The subtle but key distinction 217 between Local MAC and Split MAC relates to the non real-time 218 functions: in Split MAC architecture, the AC terminates 802.11 non 219 real-time functions, whereas in Local MAC architecture the WTP 220 terminates the 802.11 non real-time functions and consequently sends 221 appropriate messages to the AC. 223 There are several motivations for taking the Split MAC approach. 224 The first is to offload to the WTP functionality that is specific and 225 relevant only to the locality of each BSS, in order to allow the AC 226 to scale to a large number of 'light weight' WTP devices. Moreover, 227 real-time functionality is subject to latency constraints and cannot 228 tolerate delays due to transmission of 802.11 Control frames (or 229 other real-time information) over multiple-hops. The latter would 230 limit the available choices for the connectivity between the AC and 231 the WTP, hence the real-time criterion is usually employed to 232 separate MAC services between the devices. Another consideration is 233 cost reduction of the WTP to make it as cheap and simple as possible. 234 Last but not least, moving functions like encryption and decryption 235 to the AC reduces vulnerabilities from a compromised WTP, since user 236 encryption keys no longer reside on the WTP. As a result, any 237 advancements in security protocols and algorithms design do not 238 necessarily obsolete the WTPs; the ACs implement the new security 239 schemes instead, and the management and update task is therefore 240 simplified. Additionally, the network is protected against LAN-side 241 eavesdropping. 243 3. Architectural requirements 245 The following are the architectural requirements for CAPWAP protocol: 247 1) Both local MAC and split MAC technologies based products, i.e., 248 ACs or WTPs must be able to co-exist and inter-operate in one WLAN 249 access network. 251 2) ACs and WTPs MUST be able to connect by a variety of interconnect 252 technologies. CAPWAP protocol should be transmitted transparently 253 regardless of lower technologies. Examples of interconnect 254 technologies used in current architectures include Ethernet, bus 255 backplanes, and ATM (cell) fabrics. Ethernet architecture is most 256 widely used and should be recommended. 258 3) CAPWAP-supported WTPs should be able to co-exist with non-CAPWAP 259 WTPs in one WLAN access network. 261 4. User (client) access requirements 263 There shouldn't be any impact on the client (both hardware and 264 software platform) due to the use of CAPWAP protocol. Clients 265 should not be required to be aware of the existence of CAPWAP 266 protocol. 268 5. Service requirements 270 The following are the service requirements: 272 1)Voice over WLAN. So CAPWAP should support IEEE 802.11e and provide 273 fast-handoff capability to avoid voice interruption. 275 2)Isolate STA from other STAs and restrict inter-STA in layer 2 276 communication directly. 278 3)WLAN network resource share. It is required that two or more WLAN 279 service providers can share a hotspot WLAN network. This means 280 that a physical WLAN network can be virtualized into several 281 logical WLAN network. 283 6. Centralized Control requirements 285 The following are the control requirements: 287 1)AC may perform access control functions based on radio resource 288 and/or network resource. 290 2)To support handover and load balancing between different WTPS, AC 291 should have the capability of centralized control via CAPWAP protocol. 293 7. Management Requirements 295 The following are the management requirements: 296 It is possible that WTPs can be managed directly or through AC 297 where AC acts as a management agent. 299 8. Security Requirements 301 The following are the security requirements: 303 1)It is required to support WPA and/or IEEE 802.11i for wireless air 304 interface security. 306 2)It is required to provide mechanism supporting secure information 307 exchange between AC and WTP 309 9. QoS Requirements 311 The following are the QoS requirements: 313 WLAN air interface QoS implementation should be based on the current 314 IEEE802.11e, but it is required to support QoS centralized control 315 Policy between WTPS and AC via CAPWAP protocol. 317 10. References 319 1. �CAPWAP Problem Statement�, August 2004, 320 323 2. �Architecture Taxonomy for Control and Provisioning of Wireless 324 Access Points (CAPWAP)�, August 2004, 325 http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt> 327 3. �Functionality Classifications for Control and Provisioning of 328 Wireless Access Points (CAPWAP)�, July 2004, 329 332 11. Authors' Addresses 334 Wenhui Zhou 335 53A, Xibianmen Ave, Xuanwu District 336 Beijing 100053 337 P. R. China 338 Phone: +86 10 66006688 ext.3061 339 Email: zhouwenhui@chinamobile.com 341 Zhonghui Yao 342 Huawei Longgang Production Base, 343 Shenzhen 518129 344 P. R. China 345 Phone: +86 755 28780808 346 EMail: yaoth@huawei.com 348 L. Lily Yang 349 JF3-206, Intel Corp. 350 2111 NE 25th Ave. 351 Hillsboro, OR 97124 352 USA 353 Phone: +1 503 264 8813 354 EMail: lily.l.yang@intel.com 356 Meimei Dang 357 RITT,CATR 358 No.11 YueTanNanJie, Xicheng District 359 Beijing 100045 360 P.R.China 361 Phone: +86 10 68094457 362 Email: dangmeimei@mail.ritt.com.cn 364 Dong Wang 365 No.68 Zijinghua Rd,Yuhuatai District, 366 Nanjing,Jiangsu Prov. 210012 367 P.R. China. 368 Phone: +86-25-52871713 369 EMail: wang.dong@mail.zte.com.cn 371 Intellectual Property Statement 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org. 395 Disclaimer of Validity 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 400 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 402 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Copyright Statement 407 Copyright (C) The Internet Society (2004). This document is subject 408 to the rights, licenses and restrictions contained in BCP 78, and 409 except as set forth therein, the authors retain all their rights. 411 Acknowledgment 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.