1 / 11

CAPWAP Extension for 802.11n and Power/channel Reconfiguration

CAPWAP Extension for 802.11n and Power/channel Reconfiguration. Yifan Chen Dapeng Liu – Presenting Hui Deng Lei Zhu. draft-ietf-opsawg-capwap-extension-00. Background. draft-chen-opsawg-capwap-extension-00.txt was adopted as WG document after March meeting.

oprah
Télécharger la présentation

CAPWAP Extension for 802.11n and Power/channel Reconfiguration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CAPWAP Extension for 802.11n and Power/channel Reconfiguration Yifan Chen Dapeng Liu – Presenting Hui Deng Lei Zhu draft-ietf-opsawg-capwap-extension-00

  2. Background • draft-chen-opsawg-capwap-extension-00.txt was adopted as WG document after March meeting. • Valuable comments were received from Dorothy Stanley. • Appreciate for the review and comment. • Update the draft accordingly.

  3. Comments Received • (1) The  term “AP” needs to be changed to “WTP” to be consistent with RFC5415/5416 terminology. • Accepted and revised.

  4. (2) The  extensions defined in this document are specific to 802.11, so should both reference and be made relative to the 802.11 binding document, http://tools.ietf.org/html/rfc5416 ( and add to reference list) in addition to the CAPWAP protocol: https://tools.ietf.org/html/rfc5415. • Accepted and add rfc5416 in the reference list.

  5. (3) Any new message elements would be 802.11 Binding message elements (see Table 8, section 6 in RFC 5416). Thus there are IANA considerations (Section 7). • IANA section is updated. Still need more work.

  6. (4) Consider  using the IEEE 802.11 information element (See 6.6 in RFC 5416) to carry HT element information rather than defining new capwap message elements. Similarly for the Neighbor Report and Beacon Report. • Accepted and update section 4. • “This 802.11n radio capability information element may also be conveyed using the IEEE 802.11 information element by carrying the IEEE 802.11 HT element information.” • “The neigbor WTP report message element may also be conveyed using IEEE 802.11 information element by carrying 802.11 neighbor report information element.”

  7. (5) The  Channel Bind TLV “Channel Count “field does not match the description, which indicates a device type field. Make consistent or delete. Also the name of the TLV does not match its use. • Accepted and revised. • “Channel Count: The number of channel will be scanned.”

  8. (6) The  Channel Scan Report appears to be similar to the IEEE 802.11 Beacon report. Consider re-using (portions of) the Beacon reporting mechanism defined in IEEE 802.11. • Accepted and update section 5. • “The channel scan report may also be conveyed by IEEE 802.11 information element by carrying the IEEE 802.11 beacon report message element.”

  9. (7) Please  number the figures to help the reader. • Accepted and revised.

  10. Next Step • Refine IANA consideration section. • Add detail request to IANA. • Refine the text. • Remove the information element definition since 802.11 information element is reused. • Initiate WGLC soon after this meeting?

  11. Comments?

More Related