Last Modified: 2004-02-02
- Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management.
Additionally, the architecture document will contain a threat analysis that describes the security threats involved in each network architectural approach.
Specific Working Group deliverables are:
- A problem statement document, - A network architecture taxonomy document including threat analysis.
Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture
The network architecture taxonomy document, when stable, will be discussed with IEEE 802 in order to validate and synchronize this work with the work in IEEE 802. This may result in merging the work with IEEE 802 documentation in which case it may not need to be published as an RFC. Such decision will be made in co-operation with IEEE.
The CAPWAP WG will maintain a close working liaison with relevant working groups in IEEE 802.11 and IEEE 802.1. Working Group documents will be sent to an expert review board for review prior to submission to the IESG. In order to facilitate quick completion of this work, the Working Group charter will expire 6 months after it is approved by the IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the interoperability problem.
Feb 04 | Last call for problem statement draft. | |
Mar 04 | Discuss last call comments for problem statement at IETF 59. | |
Mar 04 | Last Call for architecture description document. | |
Apr 04 | Submit problem statement to IESG for publication approval. | |
May 04 | Architecture document to expert review. | |
Jun 04 | Stable Architecture document for review/sync-up with IEEE 802 | |
Jul 04 | Discuss results of IEEE 802 review/sync-up | |
Aug 04 | Close WG or Re-charter |
Control and Provisioning of Wireless Access Points WG (capwap) Wednesday, March 3 at 1530-1730 =============================== CHAIRS: Mahalingam Mani(mmani@avaya.com) Dorothy Gellert(dorothy.gellert@nokia.com) IEEE Liaison: Dorothy Stanley (dstanley@agere.com) Technical Advisor: Bob O'Hara (bohara@airespace.com) AGENDA: Agenda Bashing: 5 min. Problem Statement Draft Presentation & Discussions: 15 minutes Architecture Design team: 15 minutes Architecture Draft Presentation: 15 minutes Summary of January IEEE 802.11 meeting: 10 minutes Upcoming IEEE 802.11 meeting: 10 minutes Current Issues list: 20 minutes Functionality Classification for CAPWAP draft: 15 minutes Open Discussions & Next Steps: 15 minutes Reading List: Capwap Problem Statement: <http://www.ietf.org/internet-drafts/dr aft-ietf-capwap-problem-statement-00.txt> Capwap Architecture: <http://www.ietf.org/internet-drafts/dr aft-ietf-capwap-arch-00.txt> Functionality Classifications for CAPWAP: <http://www.ietf.org/internet-drafts/dr aft-cheng-capwap-classifications-00.txt> Mailing List: List: capwap@frascone.com Subscribe: capwap-request@frascone.com Body: subscribe in Subject line Archive: <http://mail.frascone.com/pipermail/public/capwap/> Reported by Matt Holdrege <matt@strixsystems.com> Changes since IETF 58 (see slides) Any comments on last call for the problem statement Ajit? questions on problem statement. What about mobility triggers? Deriving the privacy function that the access point provides? Dorothy we are not chartered to address mobility, but security will be addressed. Russ Housley: Need more than just one sentence on the security in the problem statement. What security concerns will be addressed by solving this problem? Pat Calhoun This document talks about the problems that people are having today. Russ: Ill think about it. ? Why are we considering 802.11? Dorothy: We are taking a small scope at this time in order to accomplish something with IEEE. After this effort is complete, we can think about re-chartering to take on other work besides 802.11. Mani: We are just working on 802.11 deployments to get an understanding of what the IETF and IEEE responsibilities are before we take on other technologies. Dorothy: Russ will provide more info on security issues for the document. Milestones: (see slide) Rohan Mahy: This seems very optimistic. It was agreed that it is optimistic but we need to sync up with the IEEE and they are being aggressive with AP definitions. Burt Wijnen: Plenty of people have signed up with the design team and the IEEE has committed to review this document. There were no more comments on the milestones. Architecture taxonomy design team: (See slides) The team has 12 members and there were about 7 present in the meeting. Expert review (see slide) Lily Yang: Architecture draft. (see slides) Questions on the speculations made? Yes there were many speculations but they will be addressed by the design team. Charlie: Given that each data point is encumbered by vendor implementation, its going to be hard to come to consensus on each data point. Mani: Why the AP functionalities are split and why people are making the choices on splits? Pat C: We should make it useful and easy for the vendors to apply their solutions to the taxonomy. ? Could you be more specific on how this taxonomy relates to layer 3? Pat: What we show is that the access points can be split at layer 2 or layer 3. Arvid: The proposed architecture needs to be scrutinized by the design team. Lily: This is only an input document to the design team. ? There is a danger by letting the vendors simply submit their architectures to the document. Dorothy: We are only taking a market survey to make sure we understand the market. We are not changing the basis of the document. Bob OHara: The design team is more of a detective team that will create a catalogue of the architectures. We will not design new architectures. Burt: The design team shall present their work to the WG via the mailing list. ? Suggest to publish a template? The March 17th date is too aggressive to submit comments. The design team will be receptive beyond that date. Dorothy Stanley IEEE status: (see slides) Burt: A good input to our document will be a list of functions that dont exist in the IEEE document. Hopefully the IEEE will accept these definitions in their documents. And we hope that the IEEE will ask for clarifications as needed. Also, the expert review is independent of the call for interested parties. We need to show what is missing from the IEEE. We hear that we need a more complete definition of an AP and we need a dialogue on this. After this group concludes with taxonomy we will decide together with the IETF on future steps. Maybe we need a flexible AP/AC protocol. Maybe something else. From the .11 perspective there may not be a definitive architecture, rather there will be many. We will work jointly IEEE/IETF to develop these architectures. Mani: Current architecture issues: (See Slides) ? Will we define policy enforcement points? Pat C: That is an 802.11 function and we wont address such functions. Parvid: Are we splitting the control function and bearer function? Pat C: we are defining architectures that work either way. Parvid: Is this a restriction for phase one or is the in the charter? We should be cautious to not preclude future work on other technologies such as CDMA or GSM, etc. James Kempf: We may take some future work in the IRTF and try to include certain other IETF WGs. ? James said that if we look at anything other than 802.11 it should be research and I totally disagree. The other link-layer technologies are the same model and we should include them here rather than relegate them to research. James: Some technologies fit and others dont. ? 1X and .16 give us the same architecture. James: The difficulties are in the details. Pat: Where do you draw the line? There are a lot of radio protocols out there and we cant take them all on. Dorothy: Our charter is focused on 802.11 only. Burt: We have fully discussed this on the mailing list and we have to focus on 802.11 for now. You are free to write a similar taxonomy document for other radio technologies and compare them to what this group does. Indpreet Singh: Why cant the AP have bindings with multiple ACs? Pat: We should include this capability for fast-failover Dorothy: These comments were from previous work and they are simply input points for our work. The architecture draft is limited to what is in the charter. The problem statement does not exclude other architectures such as autonomous APs. Hong Cheng: Capwap functional classifications: (see slides) Bob: What options need to be negotiated on each end. If we have too many options on both sides wont that impede interoperability. Cheng: Some functions cannot be split, but there are a limited set of functions that can be split and we need to declare them. Bob: If I want to develop an AP dont I need to implement all the optional functions? Lily: The AC should implement everything and the AP can make the choice of what to implement. Saravanan Govindan: You dont need to implement everything. We just want a list of classifications such as what we have in the draft. Parvid: Is there a requirement for backward compatibility. Dorothy: There is no requirement at this time. |