idnits 2.17.1 draft-ietf-capwap-objectives-00.txt: 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 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 998. ** 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: ---------------------------------------------------------------------------- == 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 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 7095 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'TBD' is mentioned on line 714, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-arch (ref. 'I-D.ietf-capwap-arch') ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-problem-statement (ref. 'I-D.ietf-capwap-problem-statement') Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAPWAP Working Group S. Govindan (Editor) 2 Internet-Draft Panasonic 3 Expires: May 2005 ZH. Yao 4 Huawei 5 WH. Zhou 6 China Mobile 7 L. Yang 8 Intel 9 H. Cheng 10 Panasonic 11 November 2004 13 Objectives for Control and Provisioning of Wireless Access Points 14 (CAPWAP) 15 draft-ietf-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 on May 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 49 This document presents a set of objectives for an interoperable 50 protocol for the Control and Provisioning of Wireless Access Points 51 (CAPWAP). It presents objectives in three categories: architecture, 52 operations and security. The primary purpose of the document is to 53 present focused requirements which when realized, will ensure 54 interoperability among wireless local area network (WLAN) devices of 55 alternative designs. These objectives will form the basis for the 56 development and evaluation of a CAPWAP protocol. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Categories of Objectives . . . . . . . . . . . . . . . . . . . 7 64 5. Architecture Objectives . . . . . . . . . . . . . . . . . . . 8 65 5.1 Interoperability Objective . . . . . . . . . . . . . . . . 8 66 5.1.1 Objective Details . . . . . . . . . . . . . . . . . . 8 67 5.1.2 Motivation and Protocol Benefits . . . . . . . . . . . 9 68 5.1.3 Relation to Problem Statement . . . . . . . . . . . . 9 69 5.1.4 Customer Requirements . . . . . . . . . . . . . . . . 9 70 5.1.5 Classification (Mandatory, Desirable, Rejected) . . . 9 71 5.2 Interconnection Objective . . . . . . . . . . . . . . . . 9 72 5.2.1 Objective Details . . . . . . . . . . . . . . . . . . 10 73 5.2.2 Motivation and Protocol Benefits . . . . . . . . . . . 10 74 5.2.3 Relation to Problem Statement . . . . . . . . . . . . 10 75 5.2.4 Customer Requirements . . . . . . . . . . . . . . . . 10 76 5.2.5 Classification (Mandatory, Desirable, Rejected) . . . 10 77 5.3 Support for Logical Networks . . . . . . . . . . . . . . . 10 78 5.3.1 Objective Details . . . . . . . . . . . . . . . . . . 11 79 5.3.2 Motivation and Protocol Benefits . . . . . . . . . . . 11 80 5.3.3 Relation to Problem Statement . . . . . . . . . . . . 12 81 5.3.4 Customer Requirement . . . . . . . . . . . . . . . . . 12 82 5.3.5 Classification (Mandatory, Desirable, Rejected) . . . 12 83 5.4 Extensibility Objective . . . . . . . . . . . . . . . . . 12 84 5.4.1 Objective Details . . . . . . . . . . . . . . . . . . 12 85 5.4.2 Motivation and Protocol Benefits . . . . . . . . . . . 13 86 5.4.3 Relation to Problem Statement . . . . . . . . . . . . 13 87 5.4.4 Customer Requirements . . . . . . . . . . . . . . . . 13 88 5.4.5 Classification (Mandatory, Desirable, Rejected) . . . 13 89 6. Operations Objective . . . . . . . . . . . . . . . . . . . . . 14 90 6.1 WLAN Monitoring Objective . . . . . . . . . . . . . . . . 14 91 6.1.1 Objective Details . . . . . . . . . . . . . . . . . . 14 92 6.1.2 Motivation and Protocol Benefits . . . . . . . . . . . 15 93 6.1.3 Relation to Problem Statement . . . . . . . . . . . . 15 94 6.1.4 Customer Requirement . . . . . . . . . . . . . . . . . 15 95 6.1.5 Classification (Mandatory, Desirable, Rejected) . . . 15 96 6.2 Resource Control Objective . . . . . . . . . . . . . . . . 15 97 6.2.1 Objective Details . . . . . . . . . . . . . . . . . . 15 98 6.2.2 Motivation and Protocol Benefits . . . . . . . . . . . 16 99 6.2.3 Relation to Problem Statement . . . . . . . . . . . . 16 100 6.2.4 Customer Requirements . . . . . . . . . . . . . . . . 16 101 6.2.5 Classification (Mandatory, Desirable, Rejected) . . . 16 102 6.3 Support for Traffic Separation . . . . . . . . . . . . . . 17 103 6.3.1 Objective Details . . . . . . . . . . . . . . . . . . 17 104 6.3.2 Motivation and Protocol Benefits . . . . . . . . . . . 17 105 6.3.3 Relation to Problem Statement . . . . . . . . . . . . 17 106 6.3.4 Customer Requirements . . . . . . . . . . . . . . . . 17 107 6.3.5 Classification (Mandatory, Desirable, Rejected) . . . 17 108 6.4 STA Admission Control Objective . . . . . . . . . . . . . 17 109 6.4.1 Objective Details . . . . . . . . . . . . . . . . . . 18 110 6.4.2 Motivation and Protocol Benefits . . . . . . . . . . . 18 111 6.4.3 Relation to Problem Statement . . . . . . . . . . . . 18 112 6.4.4 Customer Requirements . . . . . . . . . . . . . . . . 18 113 6.4.5 Classification (Mandatory, Desirable, Rejected) . . . 18 114 6.5 Centralized WTP Management . . . . . . . . . . . . . . . . 18 115 7. Security Objectives . . . . . . . . . . . . . . . . . . . . . 19 116 7.1 CAPWAP Protocol Security . . . . . . . . . . . . . . . . . 19 117 7.1.1 Objective Details . . . . . . . . . . . . . . . . . . 19 118 7.2 System-wide Security . . . . . . . . . . . . . . . . . . . 19 119 8. Objectives for Further Discussion . . . . . . . . . . . . . . 20 120 8.1 Centralized WTP Management . . . . . . . . . . . . . . . . 20 121 8.2 Security borderline Control . . . . . . . . . . . . . . . 20 122 8.3 Trust model Definition . . . . . . . . . . . . . . . . . . 20 123 8.4 IEEE 802.11i Considerations . . . . . . . . . . . . . . . 20 124 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 21 125 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 126 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 130 Intellectual Property and Copyright Statements . . . . . . . . 26 132 1. Requirements notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Terminology 140 This document follows the terminologies of [I-D.ietf-capwap-arch]. 141 Additionally, the following terms are defined; 143 Switching segment: Those aspects of a centralized WLAN that primarily 144 deal with switching or routing control and data information between 145 Wireless Termination Points (WTPs) and the WLAN controller. 147 Wireless medium segment: Those aspects of a centralized WLAN that 148 primarily deal with the end-user interface which is wireless. 149 Initially, CAPWAP focuses on IEEE 802.11 technologies but this 150 segment may also refer to other technologies such as IEEE 802.16. 152 CAPWAP framework: A term that includes the local MAC and split MAC 153 designs of the Centralized WLAN Architecture. Standardization 154 efforts are focussed on these designs. 156 CAPWAP protocol: The protocol between WLAN controller and WTPs in the 157 CAPWAP framework. It facilitates control, management and 158 provisioning of WTPs in an interoperable manner. 160 3. Introduction 162 The growth in large scale wireless local area network (WLAN) 163 deployments has brought to focus a number of technical challenges. 164 This includes the complexity of managing large numbers of wireless 165 termination points (WTPs), which is further exacerbated by 166 differences in their design. Another challenge is the maintenance of 167 consistent configurations among the numerous WTPs. The dynamic 168 nature of the wireless medium is also a concern together with WLAN 169 security. These challenges have been highlighted in 170 [I-D.ietf-capwap-problem-statement]. 172 Many vendors have addressed these challenges for large scale WLAN 173 deployments by developing new architectures and solutions. A survey 174 of the various architectures and solutions was conducted to better 175 understand the context of the challenges so as to develop 176 interoperability among them. The Architecture Taxonomy 177 [I-D.ietf-capwap-arch] is a result of this survey in which major 178 architecture families are classified. Broadly, these are the 179 autonomous, centralized WLAN and distributed mesh architectures. The 180 survey showed that the current majority of large scale deployments 181 follow the centralized WLAN architecture in which portions of the 182 wireless medium access control (MAC) operations are centralized in a 183 WLAN controller. This architecture family is further classified into 184 remote MAC, split MAC and local MAC. Each differs in the degree of 185 separation of MAC layer capabilities among WTPs and WLAN controller. 187 This document puts forth critical objectives for achieving 188 interoperability in a CAPWAP framework. It presents objectives that 189 address the challenges of large scale WLAN deployments. The 190 realization of these objectives will ensure that WLAN equipment of 191 major design types may be integrally deployed and managed. 193 4. Categories of Objectives 195 The objectives for the CAPWAP protocol are organized into three major 196 categories; architecture, operations and security. 198 Architecture objectives deal with system level aspects of the CAPWAP 199 protocol. They address issues of protocol extensibility, diverse 200 network deployments and architecture designs and differences in 201 transport technologies. 203 Operational objectives address the control and management features of 204 the CAPWAP protocol. They deal with operations relating to 205 system-wide resource management, WTP management, QoS and STA access 206 control. 208 Security objectives address potential threats to WLANs and their 209 containment. Specifically, they deal with securing the CAPWAP 210 protocol and the WLAN system as a whole. The objectives also address 211 security requirements from end-users and service providers. 213 5. Architecture Objectives 215 The architectural considerations of centralized WLAN networks are 216 fundamental to the development and evaluation of a CAPWAP protocol. 217 The objectives in this category deal with system level aspects 218 relating to protocol extensibility, diversity of network deployments 219 and differences among vendor equipment. 221 5.1 Interoperability Objective 223 Two major designs of the centralized WLAN architecture are local MAC 224 and split MAC. With the focusing of standardization efforts on these 225 two designs, it is crucial to ensure mutual interoperation among 226 them. 228 5.1.1 Objective Details 230 This objective for the CAPWAP protocol is to ensure that WTPs of both 231 local MAC and split MAC architecture designs are capable of 232 interoperation within a single WLAN. Consequently, a single WLAN 233 controller will be capable of controlling both types of WTPs using a 234 single CAPWAP protocol. Integral support for these designs comprises 235 a number of protocol aspects. 237 i. Functionality negotiations between WLAN controller and WTPs 239 Local MAC and split MAC designs differ in the degree of IEEE 802.11 240 MAC functionalities that each type of WTP realizes. The CAPWAP 241 protocol should allow WLAN controllers to determine the 242 functionalities of different WTPs as a first step in controlling 243 them. 245 ii. Establishment of alternative interfaces 247 The functionality differences among different WTPs essentially 248 equates to alternative interfaces with a WLAN controller. So the 249 CAPWAP protocol should be capable of adapting its operations to the 250 different interfaces. The definition of these interfaces is 251 dependent on the functionality differences among local MAC and split 252 MAC WTPs. It is therefore out of scope of the objectives 253 specifications. 255 [Functionality Classifications] presents additional details on these 256 two aspects. It shows how flexibility in the CAPWAP protocol may be 257 achieved so as to realize this architecture objective. 259 This objective also addresses the need for flexibly configuring WTPs 260 based on their design types and other setup aspects. 262 5.1.2 Motivation and Protocol Benefits 264 The benefits of realizing this architecture objective are both 265 technical and practical. First, there are substantial overlaps in 266 the control operations of local MAC and split MAC architecture 267 designs. As a result, it is technically practical to devise a single 268 protocol that manages both types of devices. 270 Next, the ability to operate a CAPWAP protocol for both types of 271 architectural designs enhances its practical prospects as it will 272 have wider appeal. 274 Furthermore, the additional complexity resulting from such 275 alternative interfaces is marginal. Consequently, the benefits of 276 this objective will far outweigh any cost of realizing it. 278 5.1.3 Relation to Problem Statement 280 The objective for supporting both local MAC and split MAC WTPs is 281 fundamental to addressing [I-D.ietf-capwap-problem-statement]. It 282 forms the basis for those problems to be uniformly addressed across 283 the major WLAN architectures. This is the ultimate aim of 284 standardization efforts. The realization of this objective will 285 ensure the development of a comprehensive set of solutions to the 286 challenges of large scale WLAN deployments. 288 5.1.4 Customer Requirements 290 A number of service providers and equipment vendors see benefits with 291 the combined usage of both local MAC and split MAC designs. WTPs of 292 different designs are placed in different locations so as to 293 selectively take advantage of their respective characteristics. The 294 integral support of different architectures therefore addresses 295 critical needs for the market. 297 Furthermore, since there are products of each design type already in 298 the market and widely deployed, it is necessary for CAPWAP protocol 299 to support both of them. 301 5.1.5 Classification (Mandatory, Desirable, Rejected) 303 [TBD] [This section to contain reasons for the particular 304 classification of the objective.] 306 5.2 Interconnection Objective 308 Large scale WLAN deployments are likely to use a variety of 309 interconnection technologies between different devices of the 310 network. It should therefore be possible for the CAPWAP protocol to 311 operate over the different interconnection technologies. So the 312 protocol needs to be independent of underlying transport 313 technologies. 315 5.2.1 Objective Details 317 WLAN controllers and WTPs must be able to connect by a variety of 318 interconnection technologies. The fundamental intent is for CAPWAP 319 protocol exchanges to be transparent to underlying transport 320 technologies. As a result of realizing this objective, the protocol 321 will be capable of operation over different interconnect technologies 322 including Ethernet, bus backplanes, ATM (cell) fabrics and also 323 wireless technologies such as IEEE 802.11. Ethernet architecture is 324 most widely used and should be recommended. 326 The CAPWAP protocol should have the ability to support this diversity 327 of interconnection technologies for data and control exchanges. For 328 example, VLAN tunnels are an example of an interconnection technology 329 over which CAPWAP may operate. 331 Related to this objective, is the QoS aspect of interconnection 332 technologies. Given that QoS will be enabled differently in each of 333 these technologies, the CAPWAP protocol must ensure that network 334 performance is consistent across different transport means. 335 Additionally, QoS consistency has to cover the switching segment and 336 the wireless medium segment. 338 5.2.2 Motivation and Protocol Benefits 340 [TBD] 342 5.2.3 Relation to Problem Statement 344 [TBD] 346 5.2.4 Customer Requirements 348 [TBD] 350 5.2.5 Classification (Mandatory, Desirable, Rejected) 352 [TBD] [This section to contain reasons for the particular 353 classification of the objective.] 355 5.3 Support for Logical Networks 357 Large WLAN deployments are complex and expensive. Furthermore, 358 enterprises are under pressure to improve the efficiency of their 359 expenditures. These issues are increasingly being addressed by means 360 of shared deployments. As a result, a number of logical networks 361 cover a single physical WLAN infrastructure. This way the cost of 362 deployment and management can be shared among network service 363 providers. A scenario together with additional details for such 364 shared WLANs is presented in [Functionality Classifications]. 366 5.3.1 Objective Details 368 The objective for supporting logical networks involves a number of 369 aspects. These are discussed below; 371 i. WLAN management in terms of logical groups 373 Traditionally, each WTP has represented one complete subset of a 374 larger WLAN system. However, with shared deployments, each WTP 375 represents a number of subsets of possibly a number of larger WLAN 376 systems. So with such deployments, WLANs need to be managed in terms 377 of logical groups instead of physical devices. 379 ii. Mutual separation of control and communications 381 Since different logical networks are likely to be associated to 382 different enterprises, it is crucial that control and data 383 communications among them be mutually separated. In addition to 384 being a security concern, this aspect of the objective also 385 highlights a complexity concern. Specifically, mixing of traffic for 386 different logical networks can complicate control. So the CAPWAP 387 protocol must be capable of separating traffic among logical 388 networks. VLANs and other types of tunnels may be used for this 389 purpose. 391 iii. Multiple authentication mechanisms 393 The presence of multiple logical networks within an infrastructure 394 also means there are different subscriber groups in a WLAN system. 395 Since the subscriber groups are likely to belong to different service 396 providers or WLAN domains, their authentication needs will also be 397 different. As a result, the CAPWAP protocol must be capable of 398 transferring different authentication information. For example, one 399 subscriber group may be authenticated with IEEE 802.11i with the WLAN 400 controller being the authenticator, while another group could use web 401 authentication at an alternative server. 403 5.3.2 Motivation and Protocol Benefits 405 Given the realities of cost and complexity of WLANs, a CAPWAP 406 protocol that incorporates the objective of supporting logical 407 networks ensures simpler and cost effective WLAN management and 408 deployment. A protocol that realizes this is therefore consistent 409 with the goal of reducing complexity in large scale WLANs. 411 5.3.3 Relation to Problem Statement 413 This objective for supporting logical networks addresses problem of 414 management complexity in terms of cost. Such cost complexity is 415 reduced by sharing infrastructure among a number of service 416 providers. Consequently, deployment and managements 417 cost-efficiencies are realized. 419 5.3.4 Customer Requirement 421 Businesses require the benefits of management ease by the most cost 422 effective means. This can be achieved with the objective of 423 supporting logical networks within a single set of physical WLAN 424 equipment. There are a number of ways of realizing this objective 425 some being virtual APs, VLAN tunnels and other tunnels. 427 This objective also allows for separation between providers of 428 infrastructure from services. Logical networks allows for the 429 separation of physical deployment and maintenance from actual 430 management of WLANs. This helps lower costs and responsibilities for 431 service providers. 433 5.3.5 Classification (Mandatory, Desirable, Rejected) 435 [TBD] [This section to contain reasons for the particular 436 classification of the objective.] 438 5.4 Extensibility Objective 440 Wireless technology is developing at rapid pace in a number of 441 industry and scientific groups. With such pace, it is important to 442 design CAPWAP in a way as to allow future extensibility. In 443 particular, the IEEE is in the process of specifying standards for 444 broadband wireless access, namely IEEE 802.16. There also other 445 activities within the IEEE that needs to be considered in the CAPWAP 446 context. 448 5.4.1 Objective Details 450 This objective has a number of aspects that are described below; 452 i. Enable support for future wireless technologies 453 This aspect of the objective essentially purposes that the CAPWAP 454 protocol does not rely on specifics of IEEE 802.11 technology for its 455 operations. This will simplify extensibility to support IEEE 802.16. 457 ii. Enable support for new IEEE extensions 459 The IEEE is currently reviewing IEEE 802.11 functionality. It is 460 expected that the review will result in new functional blocks, 461 interfaces or information flows. The CAPWAP protocol must be able to 462 handle these revisions with minimal changes. 464 iii. User(Client) Access Requirement 466 There should not be any impact on the end-user of CAPWAP WLAN in 467 terms of both hardware and software aspects. End-users should not be 468 required to be aware of the existence of CAPWAP protocol. 470 5.4.2 Motivation and Protocol Benefits 472 [TBD] 474 5.4.3 Relation to Problem Statement 476 [TBD] 478 5.4.4 Customer Requirements 480 Service providers are not enthusiastic about deploying technologies 481 with limited potential for extension. They require WLAN 482 infrastructure to be able to meet current and future market 483 requirements. So the objective for extensibility is critical to 484 service providers and other customers of WLAN equipment. 486 5.4.5 Classification (Mandatory, Desirable, Rejected) 488 [TBD] [This section to contain reasons for the particular 489 classification of the objective.] 491 6. Operations Objective 493 CAPWAP aims to provide an interoperable solution to the control and 494 provisioning of large scale WLAN deployments. In this context, the 495 operational objectives address functional aspects of the protocol. 496 These functions cover system monitoring, resource management and QoS. 498 6.1 WLAN Monitoring Objective 500 The scale of WLANs in the CAPWAP context results in numerous 501 information sources. For example, the configuration of each WTP can 502 be considered as an information source. Additionally, the switching 503 segment and wireless medium segment can also be considered as 504 information sources. So for effective performance, the CAPWAP 505 protocol needs to regularly monitor the various information sources. 507 6.1.1 Objective Details 509 Large WLANs need a variety of information sources to be monitored. 510 So this objective includes a number of aspects. 512 i. Configuration consistency 514 CAPWAP based WLANs include a large number of WTPs, each of which need 515 to be configured and managed. The protocol should therefore allow 516 WTPs to regularly send information on the state of their 517 configuration to their WLAN controller. Furthermore, it should also 518 be capable of consistently distributing firmware to all the WTPs. 520 ii. System-wide resource state 522 The centralized WLAN architecture is made up of a switching segment 523 and wireless medium segment. In the switching segment, network 524 congestion and WTP status, including firmware information, have to be 525 monitored. In the wireless medium segment, the dynamic nature of the 526 medium itself has to be monitored. Overall, there are also various 527 statistics that are required for operation. 529 The CAPWAP protocol should therefore be capable of monitoring various 530 information sources. Moreover, given relationships among information 531 sources, CAPWAP should combine information from such sources. For 532 example, statistics information may be merged with status signals. 533 So this aspect of the objective proposes collective information 534 arising from different information sources. Within this aspect of 535 the monitoring objective, the protocol may also allow WTPs to send 536 regular send feedback using CAPWAP. 538 6.1.2 Motivation and Protocol Benefits 540 The effectiveness of a protocol is based on the relevance of 541 information on which it operates. The objective for WLAN monitoring 542 can provide this information to the CAPWAP protocol. So there will 543 tangible benefits with this objective. 545 6.1.3 Relation to Problem Statement 547 This objective addresses the problems of management complexity. This 548 challenge is better solved with the appropriate information resulting 549 from this WLAN monitoring. With collective information from various 550 information sources, realizing this objective will help control and 551 manage complexity. 553 The objective also helps address the challenge of maintaining 554 consistent configurations among WTPs. 556 6.1.4 Customer Requirement 558 WLAN equipment customers require effective management solutions for 559 their networks. This objective will ensure such a solution by 560 providing collective information from a variety of information 561 sources. 563 6.1.5 Classification (Mandatory, Desirable, Rejected) 565 [TBD] [This section to contain reasons for the particular 566 classification of the objective.] 568 6.2 Resource Control Objective 570 Integral to the success of any wireless network system is the 571 performance and quality it can offer its subscribers. Since CAPWAP 572 based WLANs combine a switching segment and a wireless medium 573 segment, performance and quality need to be coordinated across both 574 of these segments. So QoS performance must be enforced system-wide. 576 6.2.1 Objective Details 578 This objective is for QoS over the entire WLAN system which includes 579 the switching segment and the wireless medium segment. Given the 580 fundamental differences between the two, it is likely that there are 581 alternate QoS mechanisms between WTPs and wireless service 582 subscribers and between WTPs and WLAN controllers. For instance, the 583 former will be based on IEEE 802.11e while the latter will be an 584 alternative. So resources need to be adjusted in a coordinated 585 fashion over both segments. The CAPWAP protocol should ensure that 586 these adjustments are appropriately exchanged between WLAN 587 controllers and WTPs. 589 6.2.2 Motivation and Protocol Benefits 591 A protocol that addresses QoS aspects of WLAN systems will deliver 592 high performance thereby being beneficial for subscribers and 593 resource utilization. Since CAPWAP deals with WTPs directly and with 594 the wireless medium indirectly, both of these must be considered for 595 performance. 597 For the wireless medium segment, QoS aspects in the protocol enable 598 high quality communications within the domain of a WLAN controller. 599 Since each domain generally covers an enterprise or a group of 600 service providers, such protocol performance has wide-ranging 601 effects. 603 Within the switching segment of CAPWAP, a QoS-enabled protocol 604 minimizes the adverse effects of dynamic traffic characteristics so 605 as to ensure system-wide performance. 607 6.2.3 Relation to Problem Statement 609 QoS control is critical to large WLANs and relates to a number of 610 aspects. In particular, this objective can help address the problem 611 of managing dynamic conditions of the wireless medium. 613 Furthermore, traffic characteristics in large scale WLANs are 614 constantly varying. So network utilization becomes inefficient and 615 user experience is unpredictable. 617 The interaction and coordination between the two aspects of 618 system-wide QoS is therefore critical for performance. 620 6.2.4 Customer Requirements 622 VoIP is a major application over WLANs. The basic requirement for 623 such applications is QoS. Furthermore, end-users demand quality 624 means of communications, so service providers in turn emphasize on 625 the QoS capabilities of WLAN systems. Adopting this objective will 626 ensure all demands are met. 628 6.2.5 Classification (Mandatory, Desirable, Rejected) 630 [TBD] [This section to contain reasons for the particular 631 classification of the objective.] 633 6.3 Support for Traffic Separation 635 The centralized WLAN architecture simplifies complexity associated 636 with large scale deployments. This is achieved by consolidating some 637 functionality at a central WLAN controller and distributing the 638 remaining across WTPs. As a result, WTPs and WLAN controller 639 exchange control and data among them. This objective suggests 640 separating control and data aspects of the exchanges for further 641 simplicity. 643 6.3.1 Objective Details 645 It is the aim of CAPWAP to simplify the control and management of 646 large scale WLANs. One way of achieving this is to separate control 647 and data aspects within the protocol. This will allow solutions for 648 control and data exchanges to be independently optimized. 650 6.3.2 Motivation and Protocol Benefits 652 The aim of separating data and control aspects of the protocol is to 653 simplify the protocol. It also allows for flexibility since each 654 part can be separately addressed in the most appropriate manner. 656 Furthermore, such separation can also allow separation of data and 657 control paths. This will enable remotely located WTPs to handle data 658 in alternative ways instead of forwarding them across a wide network 659 to the WLAN controller. 661 6.3.3 Relation to Problem Statement 663 Broadly, this objective relates to the challenge of managing 664 complexity in large scale WLANs. 666 6.3.4 Customer Requirements 668 This objective offers simplicity and flexibility in operation. These 669 are important issues for service providers and other enterprises 670 deploying large scale WLANs. 672 6.3.5 Classification (Mandatory, Desirable, Rejected) 674 [TBD] [This section to contain reasons for the particular 675 classification of the objective.] 677 6.4 STA Admission Control Objective 679 STA Admission control deals with client authentication, handoff 680 between WTPs, load balance, QoS etc. Access control in the CAPWAP 681 context must be based on a variety of information. This is because 682 CAPWAP combines both switching and wireless medium segments. 684 6.4.1 Objective Details 686 This objective focuses on access control based on collective 687 information from the switching and wireless medium segments. As 688 such, access to the WLAN is based on both the radio resources, i.e. 689 wireless medium segment and network resources, i.e. switching 690 segment. 692 6.4.2 Motivation and Protocol Benefits 694 Due to the scale of deployments in which CAPWAP will be employed, 695 comprehensive access control is crucial. The effectiveness of access 696 control in turn is affected by the information on which such control 697 is based. As a result, this objective has critical relevance to a 698 CAPWAP protocol. 700 6.4.3 Relation to Problem Statement 702 This objective addresses the issue of access control in large WLANs. 703 Broadly, it relates the problem of managing the complexity scale of 704 such networks. With collective information of both switching and 705 wireless medium segments, realizing this objective will help control 706 and manage complexity. 708 6.4.4 Customer Requirements 710 [TBD] 712 6.4.5 Classification (Mandatory, Desirable, Rejected) 714 [TBD] 716 6.5 Centralized WTP Management 718 Large scale WLAN deployments necessitate in centralized control. The 719 CAPWAP protocol interfaces the central control to the numerous WTPs. 720 One aspect of centralized control includes firmware distribution. 721 This objective relates to configuration aspects of the WLAN. 723 7. Security Objectives 725 Security is a major issue for any communications network and is 726 especially important for large scale WLANs. In this context, 727 security must encompass both the protocol between WLAN controller and 728 WTPs and also the WLAN system as a whole. So the following 729 objectives deal with securing exchanges between WLAN elements and 730 devising contingencies in case of physical security breaches. 732 7.1 CAPWAP Protocol Security 734 This objective addresses the security of the protocol. 736 7.1.1 Objective Details 738 [Note: This objective generally deals with the security between WTP 739 and WLAN controller. It deals with threats that arise from within 740 the network infrastructure.] 742 The CAPWAP protocol between WLAN controller and WTPs must be secured 743 such that information exchange between them is not threatened. As 744 such, it must provide confidentiality, integrity and authenticity for 745 those exchanges. 747 Furthermore, CAPWAP protocol security must ensure that rogue WTPs do 748 not breach legitimate WLAN systems. The CAPWAP protocol should 749 therefore include authentication mechanisms for WTPs. For example, 750 WTPs may be required to regularly renew their authentication states. 752 As a result of realizing this objective it should not be possible for 753 individual WTP breaches to affect the security of the WLAN as a 754 whole. So WTP mis-use will be protected against. 756 7.2 System-wide Security 758 [Note: This objective is to prevent against security threats from 759 outside the CAPWAP framework. Specifically, it addresses threats 760 posed by rogue wireless users. For example, recent discussions of 761 PMK sharing in the CAPWAP context illustrates a situation while may 762 be taken advantage of by a rogue wireless user. This objective 763 differs from that of the previous section in that it deals with 764 external threats that may affect the WLAN system. 766 The emphasis here is that there should be no ambiguities arising from 767 the CAPWAP framework that causes threats from external entities.] 769 8. Objectives for Further Discussion 771 [Note: The following are some of objectives for further discussion in 772 the WG.] 774 8.1 Centralized WTP Management 776 The CAPWAP protocol should provide an engine-mechanism to spring WTP 777 auto-configuration and/or software version updates and should support 778 integration with existing network management system. WLAN controller 779 as a management agent is optional. 781 If entities other than WLAN controllers manage some aspects of WTPs, 782 such as software downloads, the CAPWAP protocol may be used for WTPs 783 to notify WLAN controllers of any changes made by the other entities. 785 One example of transport mechanism for the CAPWAP protocol is TCP/IP. 786 This will bring more flexibility to the way in which WLAN systems are 787 deployed. 789 8.2 Security borderline Control 791 [Note: This objective addresses the issue of a large WLAN 792 infrastructure featuring the co-existence of different security 793 policies for different user groups. It deals with traffic flow 794 isolation on borderline of any two user groups or two users.] 796 8.3 Trust model Definition 798 [Note: When 802.1x authenticator role in 802.11i is relocated from 799 WTP to WLAN controller, the following needs to be clarified for 800 CAPWAP protocol development; whether there are any potential changes 801 in the trust relationship between WTP and infrastructure. If there 802 are changes, the new trust model needs to be defined.] 804 8.4 IEEE 802.11i Considerations 806 In the centralized WLAN architecture, authentication based on IEEE 807 802.11i presents options based on the location of the authenticator. 808 Particularly, if the authenticator is located within the WLAN 809 controller, means for key distribution need to be considered, whereas 810 if the authenticator is within a WTP, communications between the AAA 811 server and the WTP need to be considered. The CAPWAP protocol should 812 therefore be able to address these options. 814 9. Summary and Conclusion 816 The objectives presented in this document address architectural, 817 operational and security aspects for CAPWAP. They present a 818 framework which will be used to develop and evaluate candidate 819 protocols for managing large scale WLAN deployments. 821 10. Security Considerations 823 [Note: This section will detail the security implications of the 824 various objectives. One way to look at it would be to analyze the 825 security considerations of the Architecture Taxonomy and borrow/infer 826 from it.] 828 The objective dealing with alternative interfaces covers the 829 interoperability of WTPs from both local MAC and split MAC designs. 830 As such, a WLAN controller must be capable of securing both of these 831 design types. This may include handling different degrees of 832 security or authentication processing for the two types of WTPs. 834 In shared deployments with a number of logical networks, it is 835 crucial to ensure mutual separation of traffic among them. Access 836 control should therefore be distinct for each of the logical 837 networks. Furthermore, subscribers to different service providers 838 need to be managed based on their respective requirements, 839 subscriptions, etc. Cross exchanges need to be secured against. 841 It should be ensured that any stray exchanges be prevented with the 842 automation of discovery and initialization processes. 844 The objective for WLAN monitoring relates to security also. Wireless 845 systems need to be constantly monitored for potential threats in the 846 form of rogue WTPs or terminals. For example, profiles for DoS and 847 replay attacks need to be monitored. 849 In addition to securing protocol exchanges between devices in large 850 scale WLANs, the CAPWAP protocol should also incorporate 851 contingencies for physical security breaches. For instance, it 852 should be ensured that the network as a whole is not compromised if a 853 single AP is stolen or otherwise compromised. The protocol should 854 therefore contain measures to detect and contain physical security 855 threats. 857 11. Contributors 859 This document is the result of a merger of two individual 860 Internet-Draft submissions. The authors of both drafts have 861 contributed to shape this document. The authors are; 863 Meimei Dang 864 RITT, CATR 865 No.11 YueTanNanJie, Xicheng District 866 Beijing 100045 867 P. R. China 868 Phone: +86 10 68094457 869 Email: dangmeimei@mail.ritt.com.cn 871 Satoshi Iino 872 Panasonic Mobile Communications 873 600, Saedo-cho 874 Tsuzuki-ku 875 Yokohama 224 8539 876 Japan 877 Phone: +81 45 938 3789 878 EMail: iino.satoshi@jp.panasonic.com 880 Mikihito Sugiura 881 Panasonic Mobile Communications 882 600, Saedo-cho 883 Tsuzuki-ku 884 Yokohama 224 8539 885 Japan 886 Phone: +81 45 938 3789 887 EMail: sugiura.mikihito@jp.panasonic.com 889 Dong Wang 890 ZTE 891 No.68 Zijinghua Rd, Yuhuatai District 892 Tsuzuki-ku 893 Nanjing, Jiangsu Prov. 210 012 894 P. R. China 895 Phone: +86 25 5287 1713 896 EMail: wang.dong@mail.zte.com.cn 898 12. Acknowledgements 900 The authors would like to thank the Working Group Chairs, Dorothy 901 Gellert and Mahalingam Mani, for their support and patience with this 902 document. We would also like to thank participants of the Working 903 Group who have helped shape the objectives. In particular, the 904 authors thank Pat Calhoun and Inderpreet Singh for their invaluable 905 inputs. 907 13 References 909 [Functionality Classifications] 910 Cheng, H. et al, "Functionality Classifications for 911 Control and Provisioning of Wireless Access Points", 912 draft-cheng-capwap-classifications-01, (work in 913 progress), July 2004. 915 [I-D.ietf-capwap-arch] 916 Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 917 for Control and Provisioning of Wireless Access 918 Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in 919 progress), November 2004. 921 [I-D.ietf-capwap-problem-statement] 922 Calhoun, P., "CAPWAP Problem Statement", 923 draft-ietf-capwap-problem-statement-02 (work in progress), 924 September 2004. 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, March 1997. 929 Authors' Addresses 931 Saravanan Govindan 932 Panasonic Singapore Laboratories 933 Block 1022, Tai Seng Industrial Estate 934 #06-3530, Tai Seng Avenue 935 Singapore 534 415 936 Singapore 938 Phone: +65 6550 5441 939 EMail: sgovindan@psl.com.sg 940 Zhonghui Yao 941 Huawei Longgang Production Base 942 Shenzhen 518 129 943 P. R. China 945 Phone: +86 755 2878 0808 946 EMail: yaoth@huawei.com 948 Wenhui Zhou 949 China Mobile 950 53A, Xibianmen Ave, Xuanwu District 951 Beijing 100 053 952 P. R. China 954 Phone: +86 10 6600 6688 ext.3061 955 EMail: zhouwenhui@chinamobile.com 957 L. Lily Yang 958 Intel Corp. 959 JF3-206, 2111 NE 25th Ave. 960 Hilsboro, OR 97124 961 USA 963 Phone: +1 503 264 8813 964 EMail: lily.l.yang@intel.com 966 Hong Cheng 967 Panasonic Singapore Laboratories 968 Block 1022, Tai Seng Industrial Estate 969 #06-3530, Tai Seng Avenue 970 Singapore 534 415 971 Singapore 973 Phone: +65 6550 5447 974 EMail: hcheng@psl.com.sg 976 Intellectual Property Statement 978 The IETF takes no position regarding the validity or scope of any 979 Intellectual Property Rights or other rights that might be claimed to 980 pertain to the implementation or use of the technology described in 981 this document or the extent to which any license under such rights 982 might or might not be available; nor does it represent that it has 983 made any independent effort to identify any such rights. Information 984 on the procedures with respect to rights in RFC documents can be 985 found in BCP 78 and BCP 79. 987 Copies of IPR disclosures made to the IETF Secretariat and any 988 assurances of licenses to be made available, or the result of an 989 attempt made to obtain a general license or permission for the use of 990 such proprietary rights by implementers or users of this 991 specification can be obtained from the IETF on-line IPR repository at 992 http://www.ietf.org/ipr. 994 The IETF invites any interested party to bring to its attention any 995 copyrights, patents or patent applications, or other proprietary 996 rights that may cover technology that may be required to implement 997 this standard. Please address the information to the IETF at 998 ietf-ipr@ietf.org. 1000 Disclaimer of Validity 1002 This document and the information contained herein are provided on an 1003 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1004 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1005 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1006 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1007 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1008 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1010 Copyright Statement 1012 Copyright (C) The Internet Society (2004). This document is subject 1013 to the rights, licenses and restrictions contained in BCP 78, and 1014 except as set forth therein, the authors retain all their rights. 1016 Acknowledgment 1018 Funding for the RFC Editor function is currently provided by the 1019 Internet Society.