Prepared for 59th IETF CAPWAP WG 03 March, 2004 draft-cheng-capwap-classifications-00.txt

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