1 / 16

WLAN Functionality Split Classifications for Increased Flexibility

Addressing incompatible functional splits in WLAN devices by establishing consistent classifications and interfaces, allowing cross-architectural associations and enhancing flexibility in WLAN planning and design.

billycarter
Download Presentation

WLAN Functionality Split Classifications for Increased Flexibility

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 Functional Classifications Prepared for 59th IETF CAPWAP WG 03 March, 2004 draft-cheng-capwap-classifications-00.txt 59th IETF – CAPWAP Working Group

  2. What is the issue? (1/2) Given: Split functionality is a major industry direction Situation: 59th IETF – CAPWAP Working Group

  3. What is the issue? (2/2) Problem: Incompatible functional splits 59th IETF – CAPWAP Working Group

  4. Cause of incompatibility • Lack of consistent means for classifying functions • No common functional split • Lack of compatible interfaces between functional components 59th IETF – CAPWAP Working Group

  5. What is being done now? • Based on draft-ietf-capwap-arch-00.txt • Limit compatibility to devices of a given architecture type • i.e., to a given type of functional split • Architectural compatibility required before AP – AC operation • Capabilities Negotiations to determine which AC an AP associates with • i.e., which AC is of same architecture type as AP 59th IETF – CAPWAP Working Group

  6. Why is it not enough? • Limits deployment choices • E.g. If an enterprise starts off with Acme APs, it has to end with Acme APs • Limits flexibility in WLAN planning and design 59th IETF – CAPWAP Working Group

  7. What needs to be done? (1/2) • Allow cross-architectural associations • Let AP – AC associations go beyond architectural matches • Allow flexibility in the AP – AC interface • Let the interface adapt depending on mutual capabilities 59th IETF – CAPWAP Working Group

  8. What needs to be done? (2/2) • Establish consistent classifications for WLAN functions • Leads to greater compatibility across architectures • Establish consistent interfaces between WLAN functions • Leads to flexibility in where to place functionality, i.e., how to split 59th IETF – CAPWAP Working Group

  9. Advantages • Increased flexibility • AC accommodates APs of varying capabilities / architectures • Functionality split can be different for different APs under a single AC • Introduces flexibility in the interoperation of devices 59th IETF – CAPWAP Working Group

  10. Classifications Usage • An AP associates with any AC • Negotiations determine suitable functionality split based on established classifications • AP & AC know which functions are available at each other • Interface is adapted to suit mutual capabilities & provide complementary services • Functional split becomes flexible • Devices for different architectures from different manufacturers become compatible • E.g. APs from Acme and #1 to be able to work under one AC 59th IETF – CAPWAP Working Group

  11. Usage Details (1/5) • APs negotiate with AC to determine a flexible and optimal split in functionality • Different policies are used to determine split in the classified functions • Since classifications & interfaces are established, they can go anywhere (AP or AC) 59th IETF – CAPWAP Working Group

  12. Usage Details (2/5) • Policy 1: • Each AP processes its full functionality • AC handles the remaining functionality required for WLAN operation • So different APs operate at different levels of functionality • AC performs different sets of remaining functionality for different APs 59th IETF – CAPWAP Working Group

  13. Usage Details (3/5) Policy 1: 59th IETF – CAPWAP Working Group

  14. Usage Details (4/5) • Policy 2: • Each AP processes a subset of functionality that are common to all other APs • Even if some APs are capable of higher functionality • AC handles the remaining functionality that are common for all associated APs 59th IETF – CAPWAP Working Group

  15. Usage Details (5/5) Policy 2: 59th IETF – CAPWAP Working Group

  16. Questions? 59th IETF – CAPWAP Working Group

More Related