Campus WiFi: Case Study of IITB Wireless
- 1. Hows of a Campus WiFi Network: Case study of IITBWireless Presented by Aniruddh Rao Date: 11th Jan, 2016 1
- 2. A Few Questions •What is a Campus WiFi? •Deployment of many WiFi APs across the campus •Have a mode of management and configuration •How did it come up? And what is the need? •Started as auxiliary/secondary internet source. •With faster technologies and increased online activities, became more prominent. •Easier deployment, covers wide range of users (compared to Ethernet) • As HOTSPOTS: for additional capacity and coverage 2
- 3. A Few Questions • How is Management of large/medium scale deployment done? • Can’t be manual • Configuring/ Re-configuring individual APs is a pain and may not be consistent. • Centralized management is a good option. • Gives a global view and flexibility. • Controller talks to APs about configuration, connections etc… • Needs a protocol of communication and connection to be setup. 3
- 4. A Few Questions • Is IITB Wireless centrally managed? What features does IITB Wireless provide? • Yes. • It is a centrally managed deployment by ARUBA Networks. • Provides • Multiple networks: IITB Wireless, eduroam, IITB Guest. • Roaming • Can host temporary networks for conferences, workshops etc. • AND LOT MORE…. 4
- 5. Wireless link WAN link Tunneled data and management messages Controller A Typical Centrally Managed WiFi Deployment •Controller •Communicates to AP about connections, configurations and various other things •Pre Configured APs •Like identifying controller, what data to forward to controller, what data to accept from it etc. • A Protocol • For communication and setting up the deployment 5
- 6. Wireless link WAN link Tunneled data and management messages Controller A Typical Centrally Managed WiFi Deployment •Controller •Communicates to AP about connections, configurations and various other things •Pre Configured APs •Like identifying controller, what data to forward to controller, what data to accept from it etc. • A Protocol • For communication and setting up the deployment 6 THIS IS HOW EXACTLY IITB WIRELESS IS ALSO DEPLOYED
- 7. A Few-more Questions • How does a IITB Wireless AP look like? What all does it have? 7
- 8. A Few-more Questions • How does a IITB Wireless AP look like? What all does it have? • This is how it looks like: 8
- 9. A Few-more Questions • How does a IITB Wireless AP look like? What all does it have? • This is how it looks like: • It has 2 dual band radio cards and a PoE port (Ethernet) • On each card It hosts 3 networks eduroam, IITB-Wireless, IITB-Guest • The deployment uses non overlapping channels 1,6 and 11 respectively in neighborhood. 9
- 10. A Few-more Questions • How are different wireless networks hosted on single radio card? • Each radio card/interface has a base MAC-ID • Multiple virtual interfaces created on the card • MAC-ID will be increment of base MAC-ID • Every network is identified with SSID (Network name) and BSSID (which is MAC of interface) • How are connections to IITB Wireless, IITB Guest, eduroam different? • These networks are on different logical/virtual interfaces, equivalent to different APs • Connections to each one of them is managed independently 10
- 11. Networking in IITB Wireless • What is the IP address of AP? • What IP address do I get when I connect to IITB Wireless? • Do they lie in same Subnetwork? 11
- 12. Networking in IITB Wireless 12
- 13. Networking in IITB Wireless 13
- 14. Networking in IITB Wireless • What is the IP address of AP and what IP address do I get when I connect to IITB Wireless? Do they lie in same Subnetwork? • IP to you (your device) is given by the DHCP server of central WiFi controller. • The wireless connection belongs to the VLAN in which controller is present and not the VLAN of department. AP belongs to the VLAN where it is located. • There is a tunnel (IP in IP tunnel or a transport layer connection) from AP to Controller • How is this tunnel setup? 14
- 15. Tunnel setup Controller 10.196.96.1 10.196.96.2Gateway of EE 10.107.1.250 Internal Router at CC • Connect a Pre-configured AP
- 16. Tunnel setup Controller 10.196.96.1 10.196.96.2Gateway of EE 10.107.1.250 Internal Router at CC • Connect a Pre-configured AP 10.107.46.221
- 17. Tunnel setup Controller 10.196.96.1 10.196.96.2Gateway of EE 10.107.1.250 Internal Router at CC 10.107.46.221 • AP configured with controller address. Contacts the controller
- 18. Tunnel setup Controller 10.196.96.1 10.196.96.2Gateway of EE 10.107.1.250 Internal Router at CC 10.107.46.221 • Controller authenticates the AP and sends a reply and permission to setup tunnel
- 19. Tunnel setup Controller 10.196.96.1 10.196.96.2Gateway of EE 10.107.1.250 Internal Router at CC 10.107.46.221 • AP setups the tunnel with controller. May be a persistent connection
- 20. Tunnel setup Controller 10.196.96.1 10.196.96.2Gateway of EE 10.107.1.250 Internal Router at CC 10.107.46.221 • Any client trying to connect to this AP, data will be forwarded to controller and controller manages the connection
- 21. Roaming in IITB Wireless •How does the connection continue when I move from one floor to another? •How does the connection switch to another AP automatically? 21
- 22. Roaming in IITB Wireless •Basic Service Set and Extended Service Set •In ESS •Many APs are configured to have same SSID and security credentials •Different APs are differentiated based on BSSID (MAC) BSSID – SSID MAP •In WiFi switching connection is always client decision •Avoided as much as possible by client •Can be forced by controller by disconnecting client from certain AP •Faster handoffs have non standard key caching techniques or support IEEE 802.11 22
- 23. Roaming in IITB Wireless 23 IITB Wireless IITB Wireless Random WiFi Client moving this way
- 24. Roaming in IITB Wireless •Client switches to another AP within same ESS preferentially. •Even if signal strength of Random WiFi is more than IITB Wireless, client prefers switching to IITB Wireless 24 IITB Wireless IITB Wireless Random WiFi Client moving this way
- 25. Wireless link WAN link Tunneled data and management messages Controller Deficiencies in Existing Deployment •Can different APs be deployed in this setup •Entire setup is proprietary deployment by ARUBA •The tunnel and protocol are not standard •Is the deployment scalable? •Difficult beyond a point, as all data goes to controller 25
- 26. Addressing interoperability •Standard protocols are developed •CAPWAP - Control And Provisioning of Wireless Termination Points • By IETF • UDP based protocol - RFC 5415 • Bindings are written for 802.11 WLAN Networks RFC 5416 • TR069 – Technical Report 69; CWMP – CPE WAN Management Protocol by Broadband Forum • Protocol to configure CPE (Customer Premise Equipment) from remote ACS (Auto Configuration Server) • http/SOAP based protocol for configuration 26
- 27. Addressing Interoperability •A CAPWAP tunnel is setup between AC and WTP •Applications are written on these main threads for CAPWAP 802.11 bindings • An application to set configurations • An applications to retrieve statistics 27 Architecture of CAPWAP basedWLAN controller
- 28. Addressing Scalability • Why should all the data be tunneled? •There are 3 kind of frames in IEEE 802.11 networks •Control frames •Management frames •Data frames •Data frames can be locally bridged. •Forward only control and management frames • Does multiple controllers help? • Local controller to manage real time activities like roaming • Global controller to manage global activities like authentication 28
- 29. Addressing Scalability Wireless link Wired LAN link WAN link Control Plane
- 30. Addressing Scalability Wireless link Wired LAN link WAN link Global Controller Local Controller Control Plane
- 31. SDN for WLAN Management •What is SDN? How does it help • SDN: Software Defined Networking. Enables dynamic programming of network • Separates Control plane and data plane • Provides standard interfaces or APIs for features. Implementation may differ below this level •Is it really needed? • Yes. It makes APs light radios that forward data • Gives global view, uniform policy management • Enables interoperability by providing standard interface. •Is the solution scalable? • Yes. As the controller is not loaded with data. •Existing work? • Odin, OpenFlow wireless or OpenRoads, ethanol etc. 31
- 32. Proposed Architecture for SDN Controller 32 Hierarchical Controller Architecture o Time critical operations in local controller o Global policy management in cloud controller Access technology independent protocol o Manage Wi-Fi , Wi-Max deployments using same controller o Same controller to manage TVWS backhaul and also WLAN deployment Standard Interfaces o Enables interoperability
- 33. Proposed Architecture for SDN Controller Controller and switches: OpenFlow protocol Controller and APs: TCP based protocol (Proposed for standardization) • Wireless technology independent protocol • Bindings written to support specific wireless technology Controller to controllers: Openflow forwarded by flow visor 33 OpenFlow Controller Wireless AP Controller South Bound Interface North Bound Interface OpenFlow Switch Wireless AP Sub Controller Applications Super Controller
- 34. THANK YOU 34