idnits 2.17.1 draft-govindan-capwap-wicop-evaluation-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** 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 19 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 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 (May 2005) is 6919 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) == Unused Reference: 'I-D.ietf-capwap-problem-statement' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'I-D.narasimhan-ietf-slapp' is defined on line 619, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-arch (ref. 'I-D.ietf-capwap-arch') == Outdated reference: A later version (-04) exists of draft-ietf-capwap-objectives-02 ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-objectives (ref. 'I-D.ietf-capwap-objectives') ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-problem-statement (ref. 'I-D.ietf-capwap-problem-statement') == Outdated reference: A later version (-02) exists of draft-iino-capwap-wicop-00 ** Downref: Normative reference to an Historic draft: draft-iino-capwap-wicop (ref. 'I-D.iino-capwap-wicop') ** Downref: Normative reference to an Historic draft: draft-narasimhan-ietf-slapp (ref. 'I-D.narasimhan-ietf-slapp') == Outdated reference: A later version (-02) exists of draft-singh-capwap-ctp-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.singh-capwap-ctp' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Govindan 3 Internet-Draft S. Iino 4 Expires: October 2005 H. Cheng 5 M. Sugiura 6 Panasonic 7 May 2005 9 Evaluation of Wireless LAN Control Protocol (WiCoP) 10 draft-govindan-capwap-wicop-evaluation-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 2005 . 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 The Wireless LAN Control Protocol (WiCoP) enables control of WLANs 46 made of different types of wireless termination points. It addresses 47 an immediate concern for WLAN deployments. This draft presents an 48 evaluation of WiCoP with respect to the CAPWAP Objectives. It also 49 highlights WiCoP's advantges over other CAPWAP candidate protocols. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. WiCoP Evaluation . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 6 58 4.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 6 59 4.1.2 Support for Traffic Separation . . . . . . . . . . . . 6 60 4.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 7 61 4.1.4 Configuration Consistency . . . . . . . . . . . . . . 7 62 4.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 8 63 4.1.6 Monitoring and Exchange of System-wide Resource 64 State . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1.7 Resource Control Objective . . . . . . . . . . . . . . 8 66 4.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 9 67 4.1.9 System-wide Security . . . . . . . . . . . . . . . . . 9 68 4.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 9 69 4.1.11 Interoperability Objective . . . . . . . . . . . . . 10 70 4.1.12 Protocol Specifications . . . . . . . . . . . . . . 11 71 4.1.13 Vendor Independence . . . . . . . . . . . . . . . . 11 72 4.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 11 73 4.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 12 74 4.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 12 75 4.2.2 Support for Future Wireless Technologies . . . . . . . 12 76 4.2.3 Support for New IEEE Requirements . . . . . . . . . . 12 77 4.2.4 Interconnection Objective . . . . . . . . . . . . . . 13 78 4.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 13 79 4.3 Non-objectives . . . . . . . . . . . . . . . . . . . . . . 13 80 4.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 13 81 4.3.2 Technical Specifications . . . . . . . . . . . . . . . 14 82 4.4 Operator Requirements . . . . . . . . . . . . . . . . . . 14 83 4.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 14 84 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 6. Security Considerations . . . . . . . . . . . . . . . . . . 17 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 88 Intellectual Property and Copyright Statements . . . . . . . 19 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Terminology 98 This draft follows the terminologies of [I-D.ietf-capwap-arch] and 99 [I-D.ietf-capwap-objectives]. 101 3. Introduction 103 The Wireless LAN Control Protocol (WiCoP) [I-D.iino-capwap-wicop] 104 addresses the most important issue for current WLANs - the ability to 105 control and manage systems made up of different types of WTPs. WiCoP 106 provides this ability and enables administrators to manage WLANs with 107 a mix of local-MAC and split-MAC WTPs. 109 This document evaluates WiCoP with respect to the CAPWAP Objectives 110 [I-D.ietf-capwap-objectives] and indicates how the protocol realizes 111 those requirements. 113 4. WiCoP Evaluation 115 The CAPWAP Objectives are being devised by the CAPWAP WG as the core 116 set of requirements needed to control and provision large-scale 117 WLANs. The following sections describe how WiCoP realizes all those 118 requirements. 120 4.1 Mandatory and Accepted Objectives 122 The Mandatory and Accepted Objectives represent those requirements 123 that have been deemed of highest importance. WiCoP realizes all 124 these requirements and in doing so, delivers an effective solution 125 for managing large-scale WLANs. 127 4.1.1 Logical Groups 129 The CAPWAP protocol MUST be capable of controlling and managing 130 physical WTPs in terms of logical groups including BSSID-based 131 groups. 133 4.1.1.1 Protocol Evaluation 135 WiCoP establishes logical groups using BSSIDs for the wireless medium 136 segment and VLANs for the switching segment [WiCoP Section 6.4.1]. 137 The protocol maps the two logical groups using the BSSID-TunnelID 138 item of the Conf WTP Data message element [WiCoP Section 5.2.2]. 140 4.1.1.2 Comparison 142 The authors believe that CTP [I-D.singh-capwap-ctp] provides a 143 feature that would enhance the realization of the Logical Groups 144 objective in terms of QoS policy. For example, the CTP 'Policy' 145 field may be integrated with WiCoP's logical BSSID-TunnelID 146 configuration parameter to specify QoS attributes for the logical 147 groups. 149 4.1.1.3 Compliance 151 WiCoP completely satisfies this objective. 153 4.1.2 Support for Traffic Separation 155 The CAPWAP Protocol MUST define transport control messages such that 156 the transport of control messages is separate from the transport of 157 data messages. 159 4.1.2.1 Protocol Evaluation 161 WiCoP uses separate tunnels for data and control traffic. 162 Additionally, the protocol uses distinct VLAN tunnels for traffic 163 from different logical groups [WiCoP Section 6.4.1]. This ensures 164 that traffic flows are separated between WTPs and WLAN controller. 166 Furthermore, WiCoP uses distinct messages for control and data 167 traffic. The two are never combined. 169 4.1.2.2 Compliance 171 WiCoP completely satisfies this objective. 173 4.1.3 Wireless Terminal Transparency 175 Wireless terminals MUST NOT be required to recognize or be aware of 176 the CAPWAP protocol. 178 4.1.3.1 Protocol Evaluation 180 WiCoP does not mandate any changes to wireless terminals. The 181 specifications only address the interface between WTPs and their WLAN 182 controller. 184 4.1.3.2 Compliance 186 WiCoP completely satisfies this objective. 188 4.1.4 Configuration Consistency 190 The CAPWAP protocol MUST include support for regular exchanges of 191 state information between WTPs and WLAN controller. Examples of 192 state information include WTP processing load and memory utilization. 194 4.1.4.1 Protocol Evaluation 196 WiCoP uses the Feedback Interval timer [WiCoP Section 5.4.2] to 197 maintain regular exchanges of Feedback messages [WiCoP Section 198 5.2.3], which contain information on the configuration state of WTPs 199 and WLAN controller. This helps the WLAN controller in effecting 200 consistent configuration changes to all WTPs. 202 4.1.4.2 Compliance 204 WiCoP completely satisfies this objective. 206 4.1.5 Firmware Trigger 208 The CAPWAP protocol MUST support a trigger for delivery of firmware 209 updates. 211 4.1.5.1 Protocol Evaluation 213 WiCoP activates Firmware Download message to initiate firmware check 214 and download [WiCoP Section 5.2.3]. 216 4.1.5.2 Compliance 218 WiCoP completely satisfies this objective. 220 4.1.6 Monitoring and Exchange of System-wide Resource State 222 The CAPWAP protocol MUST allow for the exchange of statistics, 223 congestion and other WLAN state information. 225 4.1.6.1 Protocol Evaluation 227 WiCoP Feedback messages [WiCoP Section 5.2.3] together with QoS 228 Value, Statistics, Interface Error and QoS Capability message 229 elements to monitor configuration state of WTPs and WLAN Controller 230 [WiCoP Section 5.2.2]. 232 4.1.6.2 Compliance 234 WiCoP completely satisfies this objective. 236 4.1.7 Resource Control Objective 238 The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to 239 equivalent QoS priorities across the switching and wireless medium 240 segments. 242 4.1.7.1 Protocol Evaluation 244 The current specifications do not directly address this objective, 245 however WiCoP can map IEEE 802.11e requirements to VLAN priority tags 246 using the BSSID-TunnelID item of the Conf WTP Data message element 247 [WiCoP Section 5.2.2]. 249 4.1.7.2 Compliance 251 WiCoP partially satisfies this objective. 253 4.1.8 CAPWAP Protocol Security 255 The CAPWAP protocol MUST support mutual authentication of WTPs and 256 the centralized controller. It must also ensure that information 257 exchanges between them are secured. 259 4.1.8.1 Protocol Evaluation 261 WiCoP makes use of IPSec based authentication and encryption 262 mechanisms [WiCoP Section 6.3] to secure all exchanges. 264 4.1.8.2 Comparison 266 The authors feel that the use of DTLS such as in SLAPP 267 [I-D.narasimhan-ietf-slapp]is effective in addressing this objective. 268 SLAPP describes an existing mechanism that can be reused in the 269 CAPWAP context. It would be preferable for CAPWAP to use DTLS as 270 opposed to adopting a new mechanism for key exchange and protocol 271 security. 273 4.1.8.3 Compliance 275 WiCoP partially satisfies this objective. 277 4.1.9 System-wide Security 279 The design of the CAPWAP protocol MUST NOT allow for any compromises 280 to the WLAN system by external entities. 282 4.1.9.1 Protocol Evaluation 284 WiCoP does not yet address the issue of potential problems due to PMK 285 sharing. 287 4.1.9.2 Compliance 289 WiCoP does not satisfy this objective. 291 4.1.10 IEEE 802.11i Considerations 293 The CAPWAP protocol MUST determine the exact structure of the 294 centralized WLAN architecture in which authentication needs to be 295 supported, i.e. the location of major authentication components. 296 This may be achieved during WTP initialization where major 297 capabilities are distinguished. 299 The protocol must allow for the exchange of key information when 300 authenticator and encryption roles are located in distinct entities. 302 4.1.10.1 Protocol Evaluation 304 This objective brings out the important architecture condition of the 305 authenticator being located distinctly from the point of encryption. 306 WiCoP addresses this condition with the use of the Key Config message 307 [WiCoP Section 5.2.3]. Key Config is used to explicitly transport 308 the 3rd message of the four-way handshake from the authenticator 309 (WLAN controller) to the point of encryption (WTP) [WiCoP Section 310 6.5.6]. As a result of this feature, WiCoP allows the WTP to 311 calculate the KeyMIC with its KeyRSC. 313 4.1.10.2 Comparison 315 The authors believe that, based on prevailing specifications of the 316 other candidate protocols, only WiCoP explicitly addresses this 317 objective. 319 4.1.10.3 Compliance 321 WiCoP completely satisfies this objective. 323 4.1.11 Interoperability Objective 325 The CAPWAP protocol MUST include sufficient capabilities negotiations 326 to distinguish between major types of WTPs. 328 4.1.11.1 Protocol Evaluation 330 WiCoP realizes this objective of managing co-existence of WTPs of 331 different MAC designs. The protocol uses the 'M' field of the WiCoP 332 header to distinguish between local-MAC and split-MAC WTPs [WiCoP 333 Section 5.1]. 335 So for each WiCoP packet from a WTP, the WLAN controller simply 336 parses the packet header and then processes it accordingly, i.e. for 337 packets from local-MAC WTP certain MAC processing are bypassed. 339 If however, the 'M' field is not used, then the WLAN controller must 340 first parse incoming packet header and then use the parsed 341 information to perform a lookup operation to determine the type of 342 WTP and then determine how to process the packet. This is an 343 extended procedure which will adversely affect WLAN operational 344 performance. 346 So using 'M' field, a WLAN controller can handle packets from 347 different types of WTPs faster and with fewer processing steps. 349 4.1.11.2 Comparison 351 The authors believe that, based on prevalent specifications of 352 alternative candidate protocols, WiCoP realizes the Interoperability 353 Objective in the most efficient manner. 355 4.1.11.3 Compliance 357 WiCoP completely satisfies this objective. 359 4.1.12 Protocol Specifications 361 Any WTP or AC vendor or any person MUST be able to implement the 362 CAPWAP protocol from the specification itself and by that it is 363 required that all such implementations do interoperate. 365 4.1.12.1 Protocol Evaluation 367 WiCoP is a complete specification and does not require any additional 368 proprietary information to implement. 370 4.1.12.2 Compliance 372 WiCoP completely satisfies this objective. 374 4.1.13 Vendor Independence 376 A WTP vendor can make modifications to hardware without any AC vendor 377 involvement. 379 4.1.13.1 Protocol Evaluation 381 WiCoP is a complete specification and does not require any additional 382 proprietary information to implement. 384 4.1.13.2 Compliance 386 WiCoP completely satisfies this objective. 388 4.1.14 Vendor Flexibility 390 WTP vendors must not be bound to a specific MAC. 392 4.1.14.1 Protocol Evaluation 394 WiCoP is a complete specification and does not require any additional 395 proprietary information to implement. 397 4.1.14.2 Compliance 399 WiCoP completely satisfies this objective. 401 4.2 Desirable Objectives 403 The Desirable Objectives are those that are not crucial to a CAPWAP 404 protocol but would be beneficial. WiCoP realizes all these 405 requirements. 407 4.2.1 Multiple Authentication Mechanisms 409 The CAPWAP protocol MUST support different authentication mechanisms 410 in addition to IEEE 802.11i. 412 4.2.1.1 Protocol Evaluation 414 WiCoP does not prevent the operation of any authentication mechanism. 415 It is generic to support all types of authentication mechanisms. 417 4.2.1.2 Compliance 419 WiCoP completely satisfy this objective. 421 4.2.2 Support for Future Wireless Technologies 423 CAPWAP protocol messages MUST be designed to be extensible for 424 specific layer 2 wireless technologies. It should not be limited to 425 the transport of elements relating to IEEE 802.11. 427 4.2.2.1 Protocol Evaluation 429 WiCoP is generic and extensible to support future developments in 430 wireless technologies. 432 4.2.2.2 Compliance 434 WiCoP completely satisfies this objective. 436 4.2.3 Support for New IEEE Requirements 438 The CAPWAP protocol MUST be openly designed to support new IEEE 439 802.11 extensions. 441 4.2.3.1 Protocol Evaluation 443 WiCoP is generic and extensible to support future developments in 444 wireless technologies and standards. 446 4.2.3.2 Compliance 448 WiCoP completely satisfy this objective. 450 4.2.4 Interconnection Objective 452 The CAPWAP protocol MUST NOT be constrained to specific underlying 453 transport mechanisms. 455 4.2.4.1 Protocol Evaluation 457 WiCoP does not rely of the specifics of underlying transport 458 technologies. Although WiCoP uses UDP, it does not require any UDP- 459 specific information for its operation. 461 4.2.4.2 Compliance 463 WiCoP completely satisfies this objective. 465 4.2.5 Access Control 467 The CAPWAP protocol MUST be capable of exchanging information 468 required for access control of WTPs and wireless terminals. 470 4.2.5.1 Protocol Evaluation 472 WiCoP uses the Terminal Data message element [WiCoP Section 5.2.2] to 473 exchange association and authentication information on wireless 474 terminals. This is used by the WLAN controller to supervise access 475 control. 477 4.2.5.2 Compliance 479 WiCoP completely satisfies this objective. 481 4.3 Non-objectives 483 These objectives have been recognized by the CAPWAP WG as having 484 relatively lower priorities for the current phase of CAPWAP. 486 4.3.1 Support for Non-CAPWAP WTPs 488 The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and 489 existing network management systems. 491 4.3.1.1 Protocol Evaluation 493 WiCoP can configure local-MAC WTPs, which in some cases require 494 limited management. This case is similar to those of legacy WTPs. 496 4.3.1.2 Compliance 498 WiCoP completely satisfies this objective. 500 4.3.2 Technical Specifications 502 WTP vendors SHOULD NOT have to share technical specifications for 503 hardware and software to AC vendors in order for interoperability to 504 be achieved. 506 4.3.2.1 Protocol Evaluation 508 WiCoP is a complete specification and does not require any additional 509 proprietary information to implement. 511 4.3.2.2 Compliance 513 WiCoP completely satisfies this objective. 515 4.4 Operator Requirements 517 The following objective addresses the concerns of WLAN service 518 providers. 520 4.4.1 AP Fast Handoff 522 The CAPWAP protocol operations MUST NOT impede or obstruct the 523 efficacy of AP fast handoff procedures. 525 4.4.1.1 Protocol Evaluation 527 Since WiCoP addresses the centralized WLAN architecture in which 528 information can be managed across WTPs. Consequently, the protocol 529 would only serve to enhance AP fast handoff procedures instead of 530 impeding it. 532 4.4.1.2 Compliance 534 WiCoP completely satisfies this objective. 536 5. Summary 538 The evaluation presented in this document indicates that WiCoP 539 satisfies most of the crucial objectives. The authors also believe 540 that WiCoP addresses some objectives in highly efficient and 541 effective ways. 543 +---------------------------------------------------------+------------+ 544 | Objective | Compliance | 545 +---------------------------------------------------------+------------+ 546 | Logical Groups | C | 547 | | | 548 | Support for Traffic Separation | C | 549 | | | 550 | Wireless Terminal Transparency | C | 551 | | | 552 | Configuration Consistency | C | 553 | | | 554 | Firmware Trigger | C | 555 | | | 556 | Monitoring and Exchange of System-wide Resource State | C | 557 | | | 558 | Resource Control Objective | P | 559 | | | 560 | CAPWAP Protocol Security | P | 561 | | | 562 | System-wide Security | N | 563 | | | 564 | IEEE 802.11i Considerations | C | 565 | | | 566 | Interoperability Objective | C | 567 | | | 568 | Protocol Specifications | C | 569 | | | 570 | Vendor Independence | C | 571 | | | 572 | Vendor Flexibility | C | 573 | | | 574 | Multiple Authentication Mechanisms | C | 575 | | | 576 | Support for Future Wireless Technologies | C | 577 | | | 578 | Support for New IEEE Requirements | C | 579 | | | 580 | Interconnection Objective | C | 581 | | | 582 | Access Control | C | 583 | | | 584 | Support for Non-CAPWAP WTPs | C | 585 | | | 586 | Technical Specifications | C | 587 | | | 588 | AP Fast Handoff | C | 589 +---------------------------------------------------------+------------+ 590 6. Security Considerations 592 The WiCoP evaluation does not constitue any new security 593 considerations other than those addressed in the WiCoP 594 specifications. 596 7. References 598 [I-D.ietf-capwap-arch] 599 Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 600 for Control and Provisioning of Wireless Access 601 Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in 602 progress), November 2004. 604 [I-D.ietf-capwap-objectives] 605 Govindan, S., "Objectives for Control and Provisioning of 606 Wireless Access Points (CAPWAP)", 607 draft-ietf-capwap-objectives-02 (work in progress), 608 April 2005. 610 [I-D.ietf-capwap-problem-statement] 611 Calhoun, P., "CAPWAP Problem Statement", 612 draft-ietf-capwap-problem-statement-02 (work in progress), 613 September 2004. 615 [I-D.iino-capwap-wicop] 616 Iino, S., "Wireless LAN Control Protocol (WiCoP)", 617 draft-iino-capwap-wicop-00 (work in progress), March 2005. 619 [I-D.narasimhan-ietf-slapp] 620 Narasimhan, P., "SLAPP : Secure Light Access Point 621 Protocol", draft-narasimhan-ietf-slapp-01 (work in 622 progress), June 2005. 624 [I-D.singh-capwap-ctp] 625 Singh, I., "CAPWAP Tunneling Protocol (CTP)", 626 draft-singh-capwap-ctp-01 (work in progress), April 2005. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 Authors' Addresses 633 Saravanan Govindan 634 Panasonic Singapore Laboratories 635 Block 1022, Tai Seng Industrial Estate 636 #06-3530, Tai Seng Avenue 637 Singapore 534 415 638 Singapore 640 Phone: +65 6550 5441 641 Email: saravanan.govindan@sg.panasonic.com 643 Satoshi Iino 644 Panasonic Mobile Communications 645 600, Saedo-cho 646 Tsuzuki-ku 647 Yokohama 224 8539 648 Japan 650 Phone: +81 45 938 3789 651 Email: iino.satoshi@jp.panasonic.com 653 Hong Cheng 654 Panasonic Singapore Laboratories 655 Block 1022, Tai Seng Industrial Estate 656 #06-3530, Tai Seng Avenue 657 Singapore 534 415 658 Singapore 660 Phone: +65 6550 5447 661 Email: hong.cheng@sg.panasonic.com 663 Mikihito Sugiura 664 Panasonic Mobile Communications 665 600, Saedo-cho 666 Tsuzuki-ku 667 Yokohama 224 8539 668 Japan 670 Phone: +81 45 938 3789 671 Email: sugiura.mikihito@jp.panasonic.com 673 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; nor does it represent that it has 680 made any independent effort to identify any such rights. Information 681 on the procedures with respect to rights in RFC documents can be 682 found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use of 687 such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository at 689 http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at 695 ietf-ipr@ietf.org. 697 Disclaimer of Validity 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 702 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 703 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 704 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Copyright Statement 709 Copyright (C) The Internet Society (2005). This document is subject 710 to the rights, licenses and restrictions contained in BCP 78, and 711 except as set forth therein, the authors retain all their rights. 713 Acknowledgment 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society.