1. 1 Capwap issues.PPT / DD-MM-YYYY / Initials CAPWAP Issues

2. 2 Capwap issues.PPT / DD-MM-YYYY / Initials Does the work belong in the IETF? This topic has been discussed at length, and the following agreements have been made: CAPWAP cannot require any changes to the MAC or the PHY The architecture/work must be closely reviewed by the IEEE A liaison with IEEE is required (Dorothy Stanley) A technical advisor from IEEE is also required (Bob O’Hara) Defining where specific AP functions reside in an hierarchical model is fine

3. 3 Capwap issues.PPT / DD-MM-YYYY / Initials Is “Secure Download” in scope? There are concerns about this (proposed) WG working on a secure download protocol It is a generic problem CAPWAP will not include this work in the proposed charter Should be defined in another WG, if it is required

4. 4 Capwap issues.PPT / DD-MM-YYYY / Initials Why re-invent a discovery protocol? The original charter included defining a discovery protocol The (proposed) WG will recommend existing discovery mechanisms to be used

5. 5 Capwap issues.PPT / DD-MM-YYYY / Initials Is IP used in CAPWAP solely to justify it being defined in the IETF? CAPWAP is all about scaling! Enterprise networks follow the recommended distribution/core network architecture proposed by Cisco. This means that networks have a greater number of smaller subnets Using a layers 2 protocol between the AP and the AR means: A greater number of ARs per network (one per subnet), or Extending VLANs to create the perception of a larger subnet IT managers have spoken. They want to have fewer ARs, centralized in their core network. So L3 is necessary.

6. 6 Capwap issues.PPT / DD-MM-YYYY / Initials Why discuss protocol work in the charter? The previous charter included protocol milestones. The consensus is to work on a problem statement and architecture document. The (proposed) WG can re-charter afterwards

7. 7 Capwap issues.PPT / DD-MM-YYYY / Initials Get agreement on functionality split Point raised by the IESG is that one of the highest priority items is to get agreement on the functionality split (“split AP”) The architecture document will address this issue Once the document is complete, and last call is completed, we can move forward with a clear understanding of the model used

8. 8 Capwap issues.PPT / DD-MM-YYYY / Initials What about proprietary 802.11 extensions? How does CAPWAP deal with vendor proprietary extensions? While CAPWAP cannot go out of it’s way to break the basic 802.11 protocol, interoperability with undocumented features cannot be guaranteed

9. 9 Capwap issues.PPT / DD-MM-YYYY / Initials Isn’t it all about interoperability? Comment about whether CAPWAP will provide AP-AR interoperability, or if it’s just a protocol If interoperability cannot be achieved, then the WG has failed New (proposed) charter specifically includes interoperability for users Anyone’s AP can plug into any AR

10. 10 Capwap issues.PPT / DD-MM-YYYY / Initials Why is it an AR? AR was convenient (defined in IETF documents), but agree that it’s not a 100% match AR has specific connotations Let’s call it an access controller (AC), or something other than AR

11. 11 Capwap issues.PPT / DD-MM-YYYY / Initials Is the management part not a MIB issue? Highest potential area of duplication Do we need another management protocol? Justification needs to be made Let’s finish the architecture document, and let the requirements fall out from that We can then decide whether SNMP is sufficient for this problem

12. 12 Capwap issues.PPT / DD-MM-YYYY / Initials Terminology: Is CAPWAP AP lightweight? Lightweight AP: how light is light? should we drop lightweight references in favor of emphasis on varied AP-AR split agnostic to heaviness.

13. 13 Capwap issues.PPT / DD-MM-YYYY / Initials CAPWAP Security: How light should it be? Given the range of AP architectures to be supported - how lightweight should security protocol be? Frame Security (bulk encryption) It is one thing to consider security of CAPWAP exchanges it is another to include data security into the picture.

14. 14 Capwap issues.PPT / DD-MM-YYYY / Initials Security: Authentication Protocol Attributes Authentication: how many methods should be supported? Given the allowance for failover in the charter – latency may be a factor. Need to work on existing AP platforms will need to make this strong and lightweight. Newer platforms must be able to use stronger methods. the above two may be achievable in one stroke.

15. 15 Capwap issues.PPT / DD-MM-YYYY / Initials Backup

16. 16 Capwap issues.PPT / DD-MM-YYYY / Initials Charter-v2 As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the deployment, management, and usability of these networks have become evident. draft- calhoun-capwap-problem-statement-00.txt describes some of those problems. In addition, security considerations have become increasingly important as IEEE 802.11 networks have been deployed in situations where their use in accessing sensitive data must be restricted for business or other reasons. While there are many possible approaches to solving these problems, most of them involve IP-level protocols in some fashion. To the extent changes to existing IETF protocols are necessary or new IP-level protocols must be standardized to facilitate interoperability, this work is an appropriate topic for the IETF. The charter of the CAPWAP Working Group is to define a "split AP" architecture for the purpose of simplifying the deployment, management and usability of IEEE 802.11 wireless networks. The split AP architecture centralizes processing of access point (AP) management functions, such as inter-AP configuration and control, and non-realtime host functions, such as data transport and host authentication, in a management entity, typically an Access Controller (AC). The IEEE 802.11 APs continue to perform real-time host functions. The split AP architecture does not involve any changes in IEEE 802.11 standards, since the IEEE 802.11 specification says nothing about the architecture of the IEEE 802.11 access point. This new architecture has been adopted by many manufacturers, each with some variation. Creating an interoperable protocol between the AP and the AC will benefit the network operator community by allowing operators to build networks with equipment from a collection of vendors. The Working Group will attempt to utilize existing IETF protocols where possible, but will engage in new design if necessary.

17. 17 Capwap issues.PPT / DD-MM-YYYY / Initials Charter-v2 Specific Working Group work items are: Clear problem statement of CAPWAP work Description of the split AP architecture CAPWAP security requirements, defining the needs for security between the AP and the AC, both for host data transport and for AP-AC signaling and control The split AP architecture document will describe the following components Discovery of ACs by APs Auto-organization of APs and ACs into a managed wireless access network, including AC redundancy Secure Encapsulation of host data and AC-AP signaling, as necessary to address the requirements Secure Configuration of the AP by the AC

18. 18 Capwap issues.PPT / DD-MM-YYYY / Initials Charter-v2 The intent of the CAPWAP WG is to complete architecture specification as quickly as possible and thereupon enhance charter to embark on development of appropriate CAPWAP protocol. While not specifically a work item, the Working Group will attempt to make all designs as independent of the IEEE 802.11 radio protocol as possible, so that the protocol might, in the future be used with other radio protocols. However, in any situation where a tradeoff between simplicity/speed of design completion and extensibility is required, the Working Group will opt for the former. The Working Group will also co-ordinate closely with the IEEE 802.11 WG. The CAPWAP WG will maintain a close working liaison with relevant working groups in IEEE 802.11 and IEEE 802.1

19. 19 Capwap issues.PPT / DD-MM-YYYY / Initials Charter-v2 Specific non-goals of this work are: Support for general, inter-subnet micro-mobility, Interoperable APIs for downloaded AP code images, Any IP-layer work that would require changes to the IEEE 802.11 MAC layer, Dependence on yet to be approved IEEE 802.11 work or drafts, Support for an inter-AP communication protocol, like IEEE 802.11f, Direct joint development of protocols with the IEEE 802.11 WG. Working Group protocol documents and the security requirements will be sent to the Security Area Advisory Group (SAAG) for review prior to submission to the IESG. Goals and Milestones: Feb 2004 Last call for problem statement draft Mar 2004: Last Call for architecture description document Apr 2004: Submit problem statement to IESG for review Jun 2004: Submit Architecture description document to IESG for review. July 2004 Submit to IESG for publication for review. July 2004:Re-charter