Virtual Access Points

Virtual access point(s) may be defined as logical abstraction(s) built on an underlying physical device. Once defined on a physical device each virtual access point is capable of operating as an independent entity from other virtual devices defined on the same physical device. The current Atheros cards on the orbit nodes come with a MadWifi driver that supports setting up of multiple virtual access points on a single physical device.

Topologies For Virtualization Validation

Multiple Virtual Access Points, Single Physical Device

Experiments were setup to model a simple scenario as a starting point. The sample topology that was setup is indicated in the diagram. Here the single physical device on the 802.11 card was configured to act as multiple virtual access points. Nodes defined as stations were connected to the corresponding virtual access point on the same physical device by explicitly using an essid to connect to the access point. Iperf was used to make sure that all the individual links in such a scenario were working. Explicit ip address allocation with sub-netting was done to make sure that the underlying gigabit back bone was not used and the defined wireless interfaces were exercised by Iperf.

Multiple Stations Multiple Access Points

This topology is shown in the figure attached at the bottom of the page.

Limitations With the Virtual Device Declarations

• Each physical device on a Atheros card is able to support upto 4 virtual access points and a single station.
• The number of devices supported on the single physical device also depend on the order in which the devices are created.
• If a single station is defined on a physical device then no more virtual devices may be created on the same physical device.
• If a virtual access point (master) is created on a physical device then upto a single station (with the nosbeacon – this flag will disable the use of the hardware beacon timers for the station mode operation of the device.) and upto a total of 3 more virtual access point may be defined on the same underlying physical device.

Sample Tutorial

Scenario

The user request the creation of two networks on a given set of nodes. Each network will have an access point and a station. The access point and the station are bound by the same essid's and would exist in the same subnet. In the underlying architecture the user chooses the same physical interface on a node to act as a different access point on two seperate networks. The script shows that the user may be oblivious to the fact that he/she is requesting the same node to be acting as different AP's, thereby simulating the requests of two different users for two independent networks with the involvement of a common node (the virtual AP) without each others knowledge. The sample ruby script is as given below:

 code goes here

Expected Response From The Virtualized Nodehandler Script

• Smart script that detects the usage of the same physical interface for multiple (>1) virtual interfaces.
• Checks the make of the driver on the node (Intel / Atheros).
• Virtualization of Intel based cards yet to be determined, hence for intel based devices, creates the first requested virtual interface and replies with a polite error for the second request saying "device already in use, please use another device".
• If card make is Atheros, do a constraint check on the number and type of virtual interfaces supported by the card.
• On each interface creation request, check the number of interfaces already created for that physical interface and see if it is possible to create more by verification with a global interface-usage table.
• If interface creation is possible, comply, else reply with the message that resource is currently busy.

How Will This Expected Response Be Orchestrated By The Current Software Code Base

• Nodehandler receives the name of the tutorial script that needs to be used from the command line.
• …. needs more understanding of the code ….