Mobile Device Management: Service Aware Networks for Apple Devices and BYOD
March 05, 2012
By TMCnet Special Guest
, director of Product Marketing, Aerohive Networks,
Bring Your Own Device (BYOD) and the consumerization of IT may be overused as market terms, but they are unquestionably trends that are changing network architectures and mobile device manaement in almost every enterprise. In a recent survey by Dimensional Research of 750 front-line IT professionals, managers, and executives, 87 percent say that today their employees already use personal devices for work-related activities. These results are verified by more and more surveys across different verticals everyday. These devices, 80 percnet of which are identified as smart mobile devices, are simplified for ease of use and therefore enhance employee productivity. However, for the IT department, it means a shift in network intelligence and capability out of the device and puts more onus onto the network infrastructure.
The shift of network intelligence from the device to the network to faciliate BYOD presents many challenges but one of the key attirbutes of a network that helps makes BYOD and the consumerization of IT is the ability to create “Zero-Configuration Networking” available to large organizations and enterprises so that consumer devices work on the enterprise network with no end user expertise. In order to fully realize this concept the network infrastructure must become “service-aware” and simply provide service availability seamlessly across the network and control access to those services based on a users’ context – identity, location, application, and device in use. In a service-aware network, an authorized user should instantly see services available to them such as printers, video projection, and collaboration applications, without configuring their smart mobile device. This is the ultimate achievement in the attempt to make BYOD not just manageable as an IT initiative, but desirable as it makes the BYOD user both less expensive from a capital expenditure (as the employee has purchased the device) and from an operational expense as policy and service availability is set by user context and automatically connected to the end device.
Apple (News - Alert) (News - Alert) has a history of defining the future of consumer devices and is now driving change in the enterprise infrastructure and supporting technology. 72 person of the devices brought into the enterprise by users are Apple devices, according to Dynamic Research, and as such it makes most sense for networks to attempt to achieve native Bonjour awareness and control in order to support Apple’s “Zero-Configuration Networking”.
Making networks service-aware and, in turn, making BYOD with Apple devices a native part of every network is non-trivial. Bonjour (Apple’s “Zero-Configuration Networking” protocol) underlies many services that are widely used on Apple-centric networks. By monitoring Bonjour advertisements, clients can learn the location (IP address and port) of any service, and then connect to it as with any other service. Bonjour transforms the manual process of configuring IP addresses and port numbers into a “plug-and-play” experience where users reference services by type and a human-readable name. Two notable examples are AirPrint and AirPlay (News - Alert). Both advertise themselves through Bonjour to enable clients to print and display screens, respectively. AirPlay is especially valuable in many contexts for remote display from iOS devices, and the recent announcement that AirPlay will be available in the next version of Mac OS (code-named Mountain Lion) only makes it more compelling.
The capabilities that Bonjour enables are very attractive to enterprises and educational institutions for their ease of use and ability to help make BYOD initiatives more productive (where IT doesn’t have to install all the services on every device – even the ones it doesn’t own). The problem comes in when one tries to scale Bonjour from home applications to broad, multi-vendor, multi-segment networks. Because Bonjour relies on an underlying multicast DNS advertisement, it is restricted to the scope that that advertisement travels across the network. As an example, on a network that lacks the Aerohive Bonjour Gateway (News - Alert), AirPlay will only function when both the Apple TV and the display source are both attached to the same broadcast link. Client devices cannot use AirPlay unless they are attached to the same VLAN as the Apple TV. In many enterprise and education networks, this restriction is unattractive.
One of the key building blocks that Bonjour is built on is multicast DNS. Services send advertisements to a link-local IP address, and clients build a list of available services by listening to those advertisements. On networks that consist of a single broadcast domain, the use of link-local IP addressing is acceptable. Once a network is built with segmented broadcast domains for scalability, however, multicast DNS advertisements no longer reach all devices on the network. While many services will be local to the immediate network link, not all will be.
One possible approach to making the network “service-aware” is a narrow solution to bring all devices together on to the same broadcast domain. It could be possible to configure all Apple TVs throughout the network to attach to the same VLAN, regardless of the underlying topology if one uses the right WLAN equipment. However, most devices will need to use several services, so it is not generally possible to set up a VLAN for each service. If, for example, iPads need to both print and use AirPlay, then all Apple TVs and all printers must be on the same VLAN. Taken to its extreme, the network becomes a single VLAN with all available services. Such a network concentrates all traffic through a set of “choke points” that lack scalability, redundancy, and sap the network of efficiency.
A second possible approach is to forward all multicast advertisements across router boundaries. Doing so would undoubtedly make services widely available, but forwarding link-local multicasts is explicitly forbidden by the router requirements RFC. However, simply forwarding all multicast advertisements would cause an unacceptable load on the access network, both in terms of processing power on the access layer as well as on network capacity. Forwarding all multicast advertisement frames results in every service on the network being advertised on every VLAN. On a large network, not every service should be advertised network-wide. A corallary to this problem is that of advertising services from devices (printers, Apple TVs, file services, etc.) that are spread all across the enterprise or campus and span multiple VLANs. If this multicast methodology were used then there would be a “multicast direction” issue, in other words, you wouldn’t want VLAN1 services to be sent out to all other VLANs and then VLAN2 sending the multicast back across the router boundary advertising its services in return as these “blind” multicast forward mechanisms run the danger of causing a loop and harming network and service performance.
The ideal solution is to build a true gateway device that operates out-of-band of the data path and enables the entire network to be service-aware. This gateway device would take service advertisements that are restricted to a single broadcast link and makes those services available network-wide, without any client modifications or networking gymnasitics. The device could attach to the VLANs via a trunk port and make managing Apple services across an enterprise network extraordinarily simple: If a service, such as a printer, announces itself, Aerohive (News - Alert) can ensure that the printer advertisement is made available across the entire network or, if necessary, make sure its available only to the networks allowed to view the service (i.e. control the service advertisments).
Click here to see a video demonstration of this capability offered by Aerohive Networks (News - Alert).
Edited by Jamie Epstein