Monday, 10 June 2013

802.11ad - Just for Home Cinema...Right?

One of the things I love about Twitter is that once in a while you stumble across something that completely shifts your view of the world. I spotted this little nugget (posted by @wifichef) a couple of days ago, which made me significantly re-assess my view of the application of 802.11ad technology:
"A deeper dive in to High Capacity WLANs: http://t.co/L6kcx5oMI9"
Expecting another deep dive in to 802.11n high density WLANs (...small cell sizes, using 5GHz, band steering, disabling lower speeds etc.) I clicked through the link to see if I could find any new information. However, I was completely surprised to find myself looking at a whitepaper discussing the merits of 802.11ad! In fact, it actually highlighted the disadvantages of a traditional 'legacy' WiFi network - this had me hooked :)

I must admit that I had dismissed 802.11ad (which uses the 60GHz band) as a niche technology that I'd probably hardly ever see in the Enterprise environments that I tend to work in. (I must admit to having only a superficial knowledge of the 802.11ad standard though). After all, what use is a wireless technology that can only travel a few feet, particularly when you have a building of maybe hundreds or thousands of people? How could we ever design usable WiFi networks with cell sizes that small!? You might see it on some consumer-grade wireless routers, perhaps for movie streaming in the home. Beyond that...nah, I just didn't see  it taking off.

But, after reviewing this whitepaper from Wilocity, I had to pause and re-assess my view of 802.11ad. It details testing done in high density client environments using 802.11ad-capable latops. They posted some very impressive link speed and SNR results for a 'high density' of 802.11ad stations in close proximity. This was achieved by deploying a number of 802.11ad laptops, each of which had an 802.11ad wireless docking station next to it on the desk. Each desk had an equal number of laptops and docking stations around the edges of the desk (as you might expect to see in a typical office).



My first reaction was: "Well why would you do that? If each docking station is cabled anyhow, why not just pull the network cable out of the docking station and connect it in to the laptop!?". But, after some thought, I started to consider how this technology might advance in the future... 

It looks like we only have per-laptop 802.11ad docking stations at the moment (which obviously doesn't save you much in cabling, assuming each docking station is cabled). But,  perhaps wireless equipment vendors might be able to manufacture per-desk 802.11ad access points in the future, for just the users occupying that desk? If that could be coupled with fast transition to existing 802.11n/ac office-wide networks, then as users roam about the office, they could hop between 802.11n/ac & 802.11ad networks. This would provide high speed 802.11ad at a user's desk, with lower speed 802.11n/ac as they use the traditional office wide network whilst moving between desks and rooms.

These super-small cells could make the planning of high-capacity wireless networks much easier in office-type environments. Just put an AP on each desk, together with a token blanket of traditional (ceiling-mounted) WiFi coverage to provide slower-speed transit connectivity as users move around. That would certainly make HD wireless surveying a lot more straightforward!

I have no idea how much of this will be technically possible, but I could certainly see the attraction of this type of super-small cell. It is much more akin to the provision of desktop hubs or switches that regular wired network engineers could get their head around, making support and planning much easier than traditional WiFi networks. This would obviously require more cable drops around the office, but there may be some environments where the additional cabling is worth the trade-off for the additional capacity and ease of deployment.

It is going to be fascinating to see how 802.11ad evolves and whether it could introduce yet another paradigm shift around WiFi networking.

Tuesday, 28 May 2013

Cisco ACS Policy Decisions Based on SSID Name

If you're using an authentication server (such as Cisco's ACS) to make policy decisions about wireless users, there may be times when you'd like to make a decision based on the name of the SSID that the user is joining. In this article, we'll look at how you can do this.

In this article, I'm going to assuming that we are using a Cisco wireless LAN controller, together with a flavour of Cisco ACS 5.x. I've seen this method used with Cisco ACS 4.x (see references at the bottom of this article) and wouldn't be surprised if you could modify the technique for other RADIUS servers. When Googling about this subject, I don't see any results that show how to do this in ACS 5.x, so thought it was worth a quick note.

Background

In brief, when a wireless client is attempting to authenticate to an SSID on a Cisco WLC network, if 802.1x is being used to authenticate users, then various RADIUS attributes are sent to the RADIUS server (e.g. ACS) as part of the authentication handshake between the WLC and RADIUS server. One of the attributes that is sent forward to the RADIUS contains information about the source SSID. This attribute can be leveraged in the policy/decision process for authenticating users.

The attribute we are interested in is the DNIS (Dialed Number Identification Service). If we inspect this attribute in the ACS logs, we can see that the DNIS contains the MAC address of the RADIUS client (the WLC), together with the SSID name. Here is a screenshot that shows an authentication record for a client (the SSID is called "home-8021x")



Having the MAC address and SSID mixed together like this is not that useful, but by using a wildcard character to ignore the MAC address segment of the field, we can look at the SSID name. Luckily for us, the '*' character can be used to wildcard the leading part of the field (i.e. the MAC address) and allow us to just look at the SSID segment that we wish to use for our decision making process.

To be able to include the SSID in the decision making process, we have to create an End Station Filter within ACS that we can drop in to our policy rules. Here is the ACS page that we are interested in:



To match on our SSID of interest ("home-8021x"), we have to configure the end station filter as shown below (note the use of the "*" to act as a wildcard for the MAC address of RADIUS client):



Configuration Example

Once we have our End Station Filter in place, we can make some very granular decisions around authentication and authorisation of users trying to join the SSID. One area that this is very useful for is defining Service Policies. We can tie a service definition to a particular source SSID.

For reference, here is a screen-shot from the Cisco WLC GUI, showing the SSID name that we are using:



In the example below, we have a service policy called "Auth_Users_Select". You can see from the highlighted field that only authentication requests that are received from our sample SSID will hit this policy entry, as they must match the End Station Filter that contains the SSID information. 




If you are looking at your own copy of ACS whilst looking at the example shown above, you may not see all of the fields shown in this screen-shot. You may need to customize the fields shown by hitting the 'Customize' button shown at the bottom right of the screen-shot.

Caveats

There are a couple of caveats to bear in mind:
  • SSID names are case sensitive. If you aren't hitting the policy line you expect, double check the case of the SSID name in your end station filter, compared to that on your WLC
  • Bear in mind that you are using a wild-card in the end station filter. If you have similar-named SSIDs, make sure you are not filtering out an important part of the SSID name inadvertently
Conclusion

Using End Station Filters in this way gives you a powerful way of making decisions around both authentication and authorization decisions.

Particularly when considering service policy decisions within ACS, being able to associate a service with a particular SSID is valuable - each service (e.g. Corporate-data, Corporate-voice etc.) may be authenticated by their own methods using this technique.

It's also worth noting that the same effect may be achieved using the WLAN-ID RADIUS attribute which provides the (numerical) index of the SSID (this is often suggested in other configuration examples I have seen). Although using the SSID index (via the WLAN-ID RADIUS attribute) is  a valid method, unless there has been a policy of assigning the same SSID to the same index on every WLC in the network, then this may not be a feasible approach.

References

The following documents provide some very valuable references, particularly if you are looking for the ACS 4.x version of this technique:

Wednesday, 22 May 2013

Aruba Tech Field Day - 802.11ac Product Announcement


Yesterday was the official launch of Aruba's journey in to the world of 802.11ac with their online (and real-world) Tech Field Day event where they presented their products and strategy for 11ac. I was a virtual participant, watching from over here in the UK. I have to say up-front that I do not currently supply or support Aruba products, but was very interested to hear more about their views on 802.11ac, together with their product offering. There was a lot of ground covered, but here a few (brief) notes of things that I found of particular interest for the sessions I managed to view.

802.11ac

There was a very informative and lengthy discussion around 802.11ac technology, together with the lessons learned by Aruba in their testing to date. I won't cover all points here, but the headlines that stuck in my mind were:

  • Smartphones/tablets will continue to be primarily single stream, capable of 80MHz bonded channel support
  • Although 11ac brings significant speed advances, it's not the speed itself which is the advantage, it's the increase in efficiency of the WLAN which is the big win. The faster a client can get on the WLAN, send its data, and then get off, the more clients will be able to use the WLAN (which remains a shared medium). This will help to meet the growing demand for WiFi capacity
  • The highest "headline" speeds of 802.11ac will only be achieved by clients being in close proximity to an AP. The more complex modulation and signal processing required means that excellent signal quality (e.g. through excellent SNR levels) to achieve the higher speeds.
  • Sticky clients continue to be an issue (see "ClientMatch" below), which can significantly impact the efficiency of a high density WLAN. As client speeds drop as they move away from an AP, causing a bottleneck for other clients on the same AP that they are "stuck" to.

ClientMatch

A mentioned above, Aruba highlighted the ongoing issue with "sticky clients". These are clients that initially associate with an AP and then, despite 'better-choice' APs being available, remain associated as the client moves away from it. The issue with this is that the client speed will drop as the signal level falls, so that it is transmitting at lower speeds and impacting the efficiency of other clients using that same AP. If  clients can be made to prefer (and roam to) a more local AP, that will facilitate a better link speed and WLAN efficieincy, together with all of the efficiency gains that this will bring.

Aruba have a 'patented' technology, called ClientMatch which apparently looks at things from a client point of view and can 'steer' clients to better-choice APs. This technology can apparently work for all types of (legacy) client, but works best on more recent types of client that support newer 802.11 features such as 802.11k/v.

Reading between the lines, I think it analyses signal quality and signal levels from clients (at the AP end of things), together with 802.11k/v information to make some decisions about how things are looking from a client's point of view. Then, somehow (presumably through band steering and ignoring probes etc. from clients below pre-defined signal thresholds) it 'steers' them to a better AP.

We all know the types of information that are available to an AP from clients and the limited amounts of information that clients themselves will supply or act on. So, it's hard to see what there is here to actually patent. Unless there is some type of agent installed on the client (which there isn't in this case), what other unknown (patentable) mechanism could possibly be at work here? Apart from some 'secret sauce' decision making from the WLAN point of view, using known measurements and techniques, it's hard to understand what can be so unique about this. To be honest, without more information, I'm struggling with the concept of a unique offering here...

Access Points

Early on in the proceedings, Aruba presented their new 11ac access points: the AP220. There are two models, one with internal and one with external antennas. The units they had on display at the event were very impressive looking. They looked relatively light-weight (judging by the way they were being handled) and they appeared pretty sleek, as they have now dispensed with the usual air-vents to meet the 'wipe down' needs of the healthcare sector.

The AP has 2 Gigabit Ethernet ports to cater for the theoretical throughput speeds that can achieved by an AP with 2 radios (1 x 5GHz 11ac & and  1 x 2.4GHz 11n). I didn't quite get the information around the power requirements (i.e. 802.3af vs 802.3at), but looking at the datasheet, it looks like it can run in an 'Efficient Mode' with an 802.3af POE port and full funtionality mode with an 802.3at POE port. The detail on how the 2 gigabit Ethernet ports will be used (i.e. load balancing or a true trunk) was also unclear (this is still TBA on the datasheet I am looking at...).

The guys from Aruba pointed out that the AP uses less power than 'other solutions which require a plug in module' (i.e. Cisco). But, from what I see so far, both solutions require a full 3at POE port to operate with full functionality, so, I don't really see an advantage there..?

They also said that in their experience to date, you can pretty much do a one for one swap out of 11n APs for 11ac, as the general coverage patterns were broadly similar.

Lync

A Microsoft representative provided an excellent presentation around the Microsoft Lync product, which was fascinating for those of us (OK, maybe just me) who aren't that familiar with Lync. He described the challenges of trying to prioritise the different traffic flows that originate from a Lync client.  

The Lync client itself may be a number of form factors (laptop, tablet, phone), which may be the source of data, voice or video traffic. Trying to configure the QOS requirements for just those traffic types is a challenge, but throw in the fact that there is signalling traffic, some traffic is encrypted and some protocols do not use well known port ranges, and you have a whole heap of trouble.

He then went on to describe how Aruba have become a certified Microsoft Lync partner, allowing them to have access to an API that is made available from a Lync server. Having access to the API means that the Aruba wireless LAN controller can exchange information and drill down in to the detail of each Lync session, allowing decisions (such as QOS prioritisation) to be made as required. Apparently, Aruba and Microsoft have invested a lot of time in testing this exchange of information across the API, which allows better decisions to be made by the wireless network and provides much richer information to be made available on the wireless management platform.

This foray in to the Lync API was described as Aruba's move in the to brave new world of SDN: the application providing information for the network fabric to provision the resources required for an application. Exciting stuff!!! It certainly sounds like a good strategic move for both organisations. but I wonder if an open, standards-based API would be a better way to go long term (...imagine an unique API for every different application)? This (SDN) isn't an area of expertise for me, so please excuse any comments which seem mis-guided and please attribute them to my technical ignorance :)

Finally

Finally, I have to say thanks to Aruba, Microsoft and Gestalt IT for providing such open access to this event. The information presented was both valuable and fascinating. 

The event itself was very well organised (as you might expect from those Tech Field Day boys), with a great deal of both vendor material (from Aruba/Microsoft), together with the opportunity for some challenging questions from vendor-neutral folks as well. I think this open-forum approach really shows that Aruba is ready to listen, as well as very generously share, which really raises my opinion of them significantly (...not that it was low before, :) I've had no previous dealings with Aruba) .

I believe that Aruba are also going to make some of the material available from the presentations, in the form of videos and some of the slide decks - I particularly look forward to the recommended Lync QOS settings that were shared :)  I also strongly recommend that you review some of the great material that Aruba have made available about 802.11ac and their products.

This has been another very interesting and exciting chapter in the unfolding 802.11ac - thanks to Aruba, Microsoft & Gestalt IT.

References