Last Modified: 2005-01-17
| Done | Last call for problem statement draft. | |
| Done | Discuss last call comments for problem statement at IETF 59. | |
| Done | Last Call for architecture description document. | |
| Done | Submit problem statement to IESG for publication approval. | |
| Done | Architecture document to expert review. | |
| Done | Stable Architecture document for review/sync-up with IEEE 802 | |
| Done | Discuss results of IEEE 802 review/sync-up | |
| Done | Issue first Internet-Draft of CAPWAP Objectives document | |
| Feb 05 | First WGLC for CAPWAP Objectives Draft | |
| Feb 05 | Submit CAPWAP Objectives to IEEE/IETF experts review | |
| Mar 05 | Deadline to submit candidate protocol proposals to the WG | |
| Apr 05 | Second WGLC for CAPWAP Objectives Draft | |
| May 05 | Submit CAPWAP Objectives draft to IESG as Informational RFC | |
| May 05 | Shutdown WG if CAPWAP Objectives have not finalized, otherwise continue with next milestones. | |
| Jun 05 | Issue first Internet-Draft of CAPWAP Evaluation draft | |
| Aug 05 | WGLC for CAPWAP Evaluation draft | |
| Sep 05 | Submit CAPWAP Evaluation draft to IESG as Information RFC | |
| Oct 05 | Issue first Internet Draft of CAPWAP protocol | |
| Nov 05 | Issue first Internet-Draft of CAPWAP MIB | |
| Dec 05 | WGLC for CAPWAP protocol | |
| Jan 06 | Submit CAPWAP protocol to IESG as Proposed Standard RFC | |
| Jan 06 | WGLC for CAPWAP MIB | |
| Mar 06 | Submit CAPWAP MIB to IESG as Proposed Standard RFC |
| RFC | Status | Title |
|---|---|---|
| RFC3990 | I | CAPWAP Problem Statement |
|
IETF 62
CAPWAP session 3/7/05 - 3:30pm Comments on the agenda None Comments on updated milestones by the chairs None Comments on Next steps None IEEE 802.11-IETF Liason report Dorothy Stanley - AP functional description adhoc committee was formed in Sept 2004 distinction between function and device work ongoing since 9/04, to be completed in 03/05 - text to be included in TGMa draft list of documents - Additional activities of interest TGv WNM, chair is Pat Calhoun address station management and AP MIB enhancements TGt - wireless performance prediction TG TGr - fast BSS transition chair is Clint Chaplin - IEEE standards overview info on where to find 802.11 documents request letter ballot documents for IETF review - Comments on the objectives draft request for IEEE 802.11 comments when draft is available, will be sent to 802.11 members conf call to elicit comments in April get approval from the WG for the comments in May Comments - Bernard what is the path by which that work goes forward - Dorothy S areas of potential work - identification of additional work needed at 802.11 APF conf call on Wednesday to discuss official recommendation to form official liason - Haixiang question on formal procedure between the work at the two groups - Dorothy S real answers from CAPWAP WG - Haixiang what parts of the APF work are required - Dorothy S APF work is done, lots of different views on what an AP is documenting - Haixiang concern is there may not be a single view of what an AP is are there many splits possible? - Dorothy S there is no right split - Dorothy G comments from review into objectives draft recognize IEEE 802.11 as the foremost authority for AP functions IEEE 802.11 determines how to split the MAC CAPWAP objectives - Saravanan Comments - Mani simple capabilities exchange, granularity of the exchange - SG use capabilities as described in the arch taxonomy may not have to define the granularity enough to provide mechanisms - Mani any number of permutations & combinations that affect interoperability - SG protocol does not need to define permutations - JK protocol needs to define makes troubleshooting a problem dont mind large chunks of commonalities that dont have to be negotiated smaller chunks make the protocol complicated - SG its an AC issue - JK minimize choices to keep it simpler and more manageable - DG minimal set of requirements limit the different choices can be extended later hard deadlines, dont want to spend all the time on how many permutations keep the number of choices small that cover most use cases how to split the MAC, refer to APF on how to split keep the general requirements with minimal choices of diff approaches - SG arch taxonomy definitions? - JK group them into split MAC or local MAC, but dont split into tiny pieces that have to be negotiated keep it simple - Inder its not necessary to explicitly state how to the split MAC APF will not define how to split MAC is it possible that we can agree on a single split? - JK would be the easiest possible - Inder should we make it a requirement? - DG looking for a volunteer to write a draft on how to split the MAC - DS APF will list functions, but not implementations or how to split - JK protocol draft is the place to split draft should state set of functions in each group - split & local no need for a separate draft - DG draft that lists minimal set of functions and how to split or not could also be in the protocol draft - Mani goal of the objectives draft is establish sufficient basis to faclilitate protocol evaluation feedback from WG to draw the line between rigor and flexibility should the objectives draft outline the functions of the split MAC and where each function sits? QoS mapping from 11e - why is this relevant to CAPWAP? - SG two segments - switching and wireless need to manage the network as a whole - consider both segments - Mani 11e already specifies the required mapping how is different from 11e? why do we need a requirement - SG requirement merely states that we need a mapping if it already exists then thats fine - Inder Firmware distribution should CAPWAP protocol require a mechanism to send sw images to WTP? - SG Yes. - Inder agree the firmware should be separate recommend just firmware update trigger, mechanism to send fw into WTP is out of scope - DG not a mandatory requirement looking for comments on how to split the MAC other than capabilities, is there a consensus on the objectives update the draft and WGLC at the end of the month - JK idea was to get a common set of functions, a set thats exclusive to split and another for local couldnt mix and match - Haixiang should not make anyone mandatory - DG objectives should not dictate protocol design - SG need to prioritize the features/objectives - DG no feedback yet - JK were there any objections - SG some of the new ones didnt have a clear priority - LWAPP update - Mani Does the protocol negotiate encryption capabilities? - PC requirement should state that encryption in one of WTP or AC is mandatory capabilities in the join phase will include the list of encryption capabilities AC determines where the enctyption happens - Clint is the 802.11 data frame already decrypted? - PC if encryption is at the WTP then yes, if its at the AC then no - Mani do data and ctrl frames use the same security properties? - PC this is used only for ctrl frames if security is required for data, use the same algo on the wire as on the air 802.11i is between stations and AC - Mani Will PSK be part of the AC or WTP - PC configured on both, unfortunately CTP update Inder - PC IP reassembly path - WTPs across firewalls and firewalls drop it - Inder agreed - PC how are you securing the SNMP messages - IS SNMP over CTP and CTP is secured - PC fragmentation and reassembly for these - IS between AC and WTP - PC where does 11e terminate? - IS WTP, triggers for control go from WTP to AC - PC why do we need a separate control message to the AC instead of sending .11 frames? - IS for extensibility to other wireless standards - PC imposing work on ourselves for future technologies instead of passing it through - IS you may still need if signalling is required to the WTP - PC sending all MAC mgmt messages through to the AC simplifies CAPWAP work - IS all radio-related work happens at the WTP, results go up to the AC - PC if the AC solicits the information, then it sends a message to the WTP which then sends a different (MAC-compliant) message on the air interface the reverse happens in the upstream direction - JK what happens after WTP tells the AC what MAC (split or local) it supports - IS the AC ACKs what it needs the WTP to do some vendors may not support both, others might do - JK WTP vendors may support both MACs (similar to printers supporting multiple discovery protocols) ACs may not support both MACs - IS assumed that WTP will support one method, while the ACs may support both - JK protocol has to support both, AC vendors need not - PC AC has to support both, not the WTP - JK Dont think the WTP will only support one protocol should require the AC to tell the WTP what MAC to use - PC agreed requirements exist today for mixed WTPs ACs need to support both - BA confusion on the user scenarios and how networks get deployed too many variations for a light-weight environment - Clint unclear how many heterogeneous (across vendors) deployments exist - DG taxonomy draft includes multiple vendors' view of the marketplace assume market requires heterogeneous deployments - Haixiang need capability negotiation requirement - IS challenge for WG is how the negotiation will be supported need to agree on the number of variations - PC the different split MACs are useful in different environments - IS there is only one type of local MAC, but split MAC may have multiple variations - PC proposal should state how the MAC is split - Haixiang even local MAC should state clearly what goes where SG = Saravanan DG = Dorothy G DS = Dorothy S IS = Inderpreet PC = Pat Calhoun JK = James Kempf BA = Bernard Aboba |