TechNotes

Your SIP Trunking Implementation Checklist

2012-02-02T20:33:06Z

A TechNote on Unified Communications
Gary Audin, Delphi, Inc.

]]>
What is surprising is that, years later, many of these problems continue to plague the enterprise. The basics of SIP and SIP trunking are no longer new to providers, so why are these problems still surfacing?

Having knowledge of common SIP trunking issues and a checklist for dealing with them upfront can help enterprises avoid problems with their SIP trunking implementations. Some of these considerations are the same as those for T1 and PRI PSTN deployments, but enterprises must take into account that SIP uses a different transport technology and carries digital voice packets.

Common SIP Problems

First: what are the problems you might expect? Last year, The SIP School conducted a survey in conjunction with online news source Techistan of 400 industry professionals to find the most common issues encountered during SIP trunk deployment. More than half of the respondents (58%) were from the U.S.

The survey, which determined that 59% of respondents had deployed SIP and another 26% were testing or evaluating it, asked, "If you've had problems [with a SIP trunking implementation], where have the issues been?" The respondents' answers are shown in Figure 1.
The issues are associated with three areas: the SIP trunk provider, the edge devices (network address translation, NAT; and session border controller, SBC), and the PBX and its configuration. The largest number of respondents said their problems stemmed from the PBX and its configuration, but the other areas were also generously represented.

The SIP School survey also found a number of specific problems with providers, as shown in Figure 2.

Sidestepping Trouble

Now that you can see where the problem areas tend to fall, your first step is to determine which features and functions your enterprise already has in place and what the SIP trunk can provide in required services and operation. The enterprise can obtain reports from its current PBX (whether it is IP-based or not) that describe existing trunk connections and utilization. Such reports provide a foundation for developing the trunk traffic requirements. Here are some important questions to ask when doing so:

Will secure encrypted connections be required?
Will the G.711 codec or compressed voice using G.729 be used?
Will teleworker connections be supported?
Does the IP PBX or legacy PBX support SIP? If so, is the support proprietary or for the standard SIPconnect Technical Recommendation ?
What is the schedule for SIP trunking implementation?
Should multiple Internet telephony service providers (ITSPs) be selected and tested for a SIP trunking pilot?

The second step should include an RFP that clearly spells out the enterprise's requirements. SIP trunking is new for most enterprises, and it's not like the commodity PSTN connections of T1 and PRI, which are typically differentiated only by price. The SIP trunking RFP will be different from past procurements in a number of ways:

Voice, data and video might go over the same SIP trunk.
Local, long-distance and international calling might vary by service package and provider.
A major goal is cost reduction, so the provider's proposal must demonstrate savings and include all costs for installation and any needed modifications to the IP PBX or PBX to connect to the SIP trunk.
Voice quality requirements might call for the use of Multi-Protocol Label Switching (MPLS) or Virtual Private LAN Services (VPLS) network services, which could increase the cost.
The provider might not connect to other ITSPs; if so, many of the calls will be off-network at a higher cost.
The enterprise might want the SBC and media gateway to be provided and supported by the ITSP.
The provider's pricing plans for HD voice, T.38 fax and hosted solutions might or might not be attractive.
The support of Microsoft Lync necessitates TCP for SIP signaling - not a common requirement.

SIP trunking should be trialed and tested with two ITSPs. All features in use with the T1/PRI connections should be tested over the SIP trunks. And all issues listed in Figure 2 should be tested for successful implementation.

RIM CEO Shakeup: It's a Start

2012-01-31T20:15:55Z

A TechNote on Wireless and Mobility
Joanie M. Wexler
Technology Analyst/Editor
Editorial Director, TechNotes

]]>
The company is already scurrying to find a chief marketing officer "ASAP," said Thorsten Heins, the company's newly appointed CEO, in a conference call last week. "This is an element we need to strengthen." RIM has been minus a CMO since last March, when Keith Pardy left the company.

Heins, who has been with RIM since late 2007 in a co-chief operating officer role and who was formerly chief technology officer at Siemens AG, acknowledged that the company needs to "have more of an ear to the consumer market and understand trends."

Catching Up with the Times

RIM has long had a strong reputation in the enterprise. However, its more recent growth was coming from the consumer market - that is, until iPhone and Android-based smart phones hit the shelves and consumers started ditching their loyalty to RIM. Change at the top has been sorely needed ever since.

Lazaridis and Balsillie have stepped aside to let Heins take the helm, though the two will remain on the company's board. The board also unanimously named current director and former Toronto Stock Exchange CEO Barbara Stymiest independent board chair.

The shakeup follows a year of pitfalls, missteps and bad luck for RIM. The company recently took a $485 million write-down because of unsold PlayBook tablet computers, for example. It slashed the price of its entry-level BlackBerry smart phone to $299 and forecast fewer unit sales for next quarter. It also missed important delivery dates for handset and tablet upgrades.

"Mike and Jim's departure was long overdue," says Michael Finneran, principal of mobility consulting firm dBrn Associates, and longtime RIM watcher. "RIM is still profitable, has 75 million subscribers and a globally recognized brand," he acknowledges. Yet the company has yet to produce a touchscreen phone to rival the iPhone or Android experience, he says. And the long-awaited BlackBerry 10 (formerly "BBX") devices built on the operating system technology RIM acquired with QNX Software Systems in 2010 aren't due to ship until later this year.

Heins confirmed that the once-delayed PlayBook 2.0 software is now still on track to ship in February, will include a native email client and will have the ability to run Android applications.

Beware Complacency in the Enterprise

And what of the 250,000 enterprise customers RIM says it currently serves?

Yesterday, RIM announced the general availability of BlackBerry Business Cloud Services for Microsoft Office 365, which extends Microsoft Exchange Online to BlackBerry smartphones and allows customers to manage their BlackBerry deployments in the cloud. And the company said last month that its BlackBerry Mobile Fusion multi-OS mobile device management (MDM) system, initially due in late 2011, would finally ship in early 2012. As of this writing, however, the BlackBerry Mobile Fusion Web site simply states "Coming in 2012."

Multi-OS MDM has become table stakes in today's "bring your own device," or BYOD, business settings. RIM management and security has only worked with its own devices, meaning businesses that use a mix of BlackBerry, Apple iOS, Android and other mobile OSs need separate management systems, which could be a deterrent to RIM solutions going forward.

Heins asserted last week: "We're well positioned with enterprises and CIOs." And, indeed, highly security-conscious enterprises have said in the past that they'd remain with RIM until consumer-class suppliers can prove that their platforms are as airtight as the BlackBerry system.

But RIM shouldn't get complacent about its business following, either.

"We've been looking at moving away from RIM for awhile because its technology is just too antiquated compared to the new stuff coming out," says the telecommunications manager at an Arlington, Va., financial services firm. "Even the new touchscreen version is a pale image of what iPhone and Android platforms have accomplished."

Still, RIM has money in the bank, and it's far more challenging for existing businesses to extricate themselves from their RIM investments than it is for consumers to just swap out a phone or a tablet.

What's Become of WAN Innovation?

2012-01-26T15:23:18Z

A TechNote on The Next Generation
Jim Metzler
Distinguished Research Fellow and Co-Founder
Webtorials Analyst Division

]]>
Not really, and here's the situation: The modern WAN got its start in 1969 with the deployment of ARPANET, the precursor to today's Internet. As the Internet continued to evolve to provide universal connectivity, the 20-year period that began in 1985 saw the deployment of four distinct generations of enterprise WAN technologies. These technologies were designed to provide connectivity primarily within the enterprise and between the enterprise and its key contacts (e.g., partners and suppliers).

As a result of all of this innovation in WAN services, many IT organizations' WANs grew to include myriad technologies and services.

Traditional WAN Services Wane

However, as highlighted in the Webtorials 2011 Cloud Networking Report, that situation is changing rapidly. The report contained the results of a survey in which 108 respondents were asked to indicate the extent to which they currently use each of 11 WAN services, including frame relay and asynchronous transfer mode (ATM). Not too long ago, these services were widely deployed. However, more than half the survey respondents have no frame relay in their networks, and almost two thirds have no ATM.

In addition, few IT organizations are increasing - and many are actually decreasing - their use of these technologies. The survey results clearly indicated that the primary WAN services currently used by IT organizations are MPLS, Virtual Private LAN Service (VPLS, a variation of MPLS) and the Internet.

Survey respondents were also asked to forecast any changes in their organizations' use of MPLS, VPLS and the Internet over the next year. The table below shows the percentage of the survey respondents who indicated an increase in the use of those services.

The data in the table clearly indicate that, while IT organizations will increase their use of both MPLS and the Internet, they will make a significantly greater increase in their reliance on the Internet.

No Clear MPLS Successor

In contrast to the 20-year period ending in 2005, today there is no fundamentally new generation of WAN technology under development. This means that, given the long time it takes for any new WAN technology to become mainstream, MPLS will have no clear successor in the foreseeable future.

This situation should definitely raise concerns for two reasons. First, the amount of traffic traversing the WAN continues to soar. How will we accommodate it? Second, unlike other components of the IT realm, such as processors and memory, the WAN does not follow Moore's Law (i.e., doubling in performance every 18 months); hence the unit cost of the WAN will just keep rising.

What innovation is occurring today involves variations on existing WAN technologies and services. One example of that phenomenon is VPLS, where an Ethernet frame is encapsulated in MPLS. Future TechNotes will describe some additional emerging WAN service options based on variations in current services - most notably those that make the Internet perform more like MPLS. Will these new services be enough to meet enterprise WAN needs in the coming years? It's just too early to tell.

At the upcoming Interop conference in Las Vegas, I will moderate a session titled "How to Redesign Your WAN" on Wednesday, May 9, 10:15-11:15 a.m. Please attend and learn more about this important topic.

Does the Recent WPS Attack Affect You?

2012-01-25T23:48:57Z

]]>
But look-alike acronyms and diverse implementations have created confusion about real-world impact. How can you tell if this attack impacts you?

WPS, WPA, WP-Whatever

Start with what WPS is - and isn't. The "S" in "WPS" refers to "setup." Specifically, WPS is a Wi-Fi Alliance innovation, created to encourage secure wireless connections by auto-configuring Wi-Fi Protected Access (WPA/WPA2)- Personal pre-shared keys (PSKs).

Before WPS, network owners had to configure routers with long, complex WPA2-Personal passphrases (from which PSKs are derived). End users then painstakingly re-typed those same passphrases into Wi-Fi laptops, smartphones, Tivos, Wiis, etc. Mistakes proved frustratingly common, especially on consumer electronic devices without keyboards.

To greatly simplify setup, WPS auto-configures PSKs by conducting an over-the-air exchange between router and client. Depending on router make/model, setup might require typing a four-digit PIN into a client, pushing a button on the router, or holding a client up to a router that supports near-field communications (NFC). Viehböck analyzed this supposedly secure WPS exchange and found vulnerabilities that facilitate WPS PIN cracking.

However, Viehböck's attack does NOT crack WPA/WPA2 (a.k.a. 802.11i), the standards actually used to secure wireless network traffic. This means that businesses using only WPA2-Enterprise (802.1X) needn't be concerned about WPS attacks. Neither should organizations using WPA2-Personal on enterprise-grade Wi-Fi access points that don't implement WPS.

PIN-pointing the Problem

On the other hand, SMB and residential wireless router owners who use WPA2-Personal to secure their networks should be concerned and perhaps take action.

The brute-force attack reported by Viehböck reduces the number of PINs that a would-be intruder must try before correctly guessing a WPS-enabled router's PIN. For some routers, worst-case time-to-crack is roughly four hours. For other routers, cracking could take up to 90 days - or even forever. Having cracked a router's WPS PIN, the intruder can freely connect any new client, gaining access to other connected systems and uplinked networks just like legitimate clients.

Why the range in attack duration? A brute-force attack works by repeatedly trying all possible combinations until the right PIN is guessed. Some routers ignore WPS failures, letting an attacker keep on plugging without delay. Other routers respond to repeated failures with some sort of "lockdown" period during which WPS attempts are ignored. Maximum time-to-crack depends on how many failures are permitted, how long the lockdown lasts and whether manual action is required to re-enable WPS. Furthermore, some routers engage in WPS for only a few minutes after the owner explicitly enables this auto-configure option.

Protect Yourself

Unfortunately, the affected Wi-Fi routers are relatively easy to attack; proof-of-concept tools are already freely available. Furthermore, initial (not necessarily representative) surveys indicate that about one-quarter of all Wi-Fi routers now using WPA/WPA2-Personal could be vulnerable. For those unlucky enough to be vulnerable, quick action is warranted. Fortunately, the remedy might be easy.

Anyone using a residential or SMB Wi-Fi router with WPA/WPA2-Personal should start by determining whether the router's make/model even supports WPS. A list of Wi-Fi-certified WPS-capable products can be found at www.wi-fi.org. Those with non-Wi-Fi certified products should browse product configuration guides or screens, looking for a function that sounds like WPS but might be called something else.

Those using routers that support WPS should dig further to determine actual risk exposure and ways to reduce or eliminate it. A community-sourced list of volunteer-tested routers (by make, model and firmware version) has been shared here at Google Docs. In particular, note the "WPS can be disabled" column, which describes whether, and sometimes how, to turn WPS off in each tested router.

Further information about this attack, affected products and recommended workarounds has been published by the US-CERT here. Ultimately, vendors selling especially vulnerable WPS-capable products might release updated firmware to add lockdown mechanisms or take other steps to deter this attack. In the meantime, turn WPS off wherever possible, or enable WPS only when actively attempting to auto-configure a new client.

Shown are WPS options in a common residential Wi-Fi router. Remedies to deter attack vary by product; here, just choose "Manual" in lieu of PIN or push-button auto-configuration.

Single- vs. Multi-Vendor Approaches to UC

2012-01-23T14:03:34Z

A TechNote on Unified Communications
Gary Audin, Delphi, Inc.

]]>
Working with a single vendor, especially a known incumbent, can make IT management feel more comfortable and potentially reduce implementation problems. But it probably won't provide the lowest price with the greatest menu of UC features.

On the other hand, using multiple vendors will force the enterprise to manage many different relationships. The various vendors' products might not interoperate or deliver a common user interface. And if the enterprise brings in the cloud for some UC services, these multi-vendor issues will likely increase.

Sometimes the single-vendor approach is a continuation of an existing vendor relationship. The vendor is familiar with the enterprise's operations, its present environment and its long-term goals. It builds on history, having previously won executive approval for other projects. Assuming the enterprise has been satisfied with the relationship in the past, the single incumbent vendor is sometimes selected because this decision presents a much lower career risk for the CIO than gambling on a selection of multiple new vendors.

However, a multi-vendor scenario might sometimes be impossible to avoid. If it is necessary that the UC features be accessible through mobile devices and networks, then multiple vendors will certainly be involved. In many cases it is also likely that management systems provided by third parties will enhance the capabilities of those offered by any single vendor.

Consider Help from a VAR

If a multi-vendor solution is deemed appropriate, the enterprise might want to contract with a value-added reseller (VAR) that will assume all implementation and operational responsibilities. This approach reduces technical complexity as well as problem-solving and staffing issues the enterprise will face. Furthermore, it offers a single point of contact while delivering the benefits of the multi-vendor approach.

Ultimately, the single- or multi-vendor decision will depend on an enterprise's specific requirements. Often the deciding factors are non-technical ones: e.g., previous vendor relationships, perceived vendor stability, personal preferences of IT personnel or executive management, solution cost (though with non-government entities, cost is often not the driving force).

Further Reading

There are two Webtorials papers in particular that can help you more fully understand the operation and management of multiple-vendor platforms and devices. They are "Unified Communications Solutions and Interoperability" and "Managing Multi-Vendor UC and Collaboration in a Virtual World".

Primary Pro/Con Decision Considerations

The Role of Data Center Bridging in LAN-SAN Convergence

2012-01-19T23:51:26Z

A TechNote on The Next Generation
Jim Metzler
Distinguished Research Fellow and Co-Founder
Webtorials Analyst Division

]]> As recently reported in TechNotes, a number of companies intend to complete at least a moderate deployment of LAN-SAN convergence over the next two years. But just what will it take to bring that about?

Lessons from the VoIP Trenches

Certainly this isn't the first time two complementary technologies with significant differences have been converged. Take VoIP, for example. Looking at the hurdles that were overcome to bring data and voice together and make VoIP a marketplace reality can provide tremendous insight into the challenges that a converged data center LAN presents.

A major obstacle to early VoIP implementation was that the quality of a voice call is sensitive to delay, jitter and packet loss, and the data networks of that era lacked the mechanisms to minimize these metrics to ensure acceptable performance levels. In the years following VoIP's introduction, numerous techniques - among them sophisticated congestion control mechanisms - were introduced into data networks, enabling successful VoIP implementations by the vast majority of IT organizations.

A somewhat similar situation applies in LAN-SAN convergence. In particular, traditional Ethernet provides only a best-effort service that allows buffers to overflow during periods of congestion; it relies on upper-level protocols such as TCP to manage congestion and recover lost packets through retransmissions. In an integrated LAN-SAN, this could result in a level of delay that is unacceptable for storage functions.

To emulate the lossless behavior of a Fibre Channel (FC) SAN, Ethernet needs enhanced flow-control mechanisms that eliminate buffer overflows for high-priority traffic such as storage-access flows. Lossless Ethernet is based on a set of standards commonly referred to as IEEE Data Center Bridging (DCB).

DCB's Key Components

DCB has three key components. One is the IEEE 802.1Qbb Priority-based Flow Control (PFC) standard, which allows the creation of eight distinct virtual link types on a physical link, with each virtual link mapped to an 802.1p traffic class. Every virtual link can be allocated a minimum percentage of the physical link's bandwidth. Flows are controlled on each virtual link via a pause mechanism, which can be applied on a per-priority basis to prevent buffer overflow and eliminate packet loss due to link-level congestion.

The second key component of DCB is the IEEE 802.1Qau Congestion Notification (CN) standard. This standard focuses on traffic-management techniques that eliminate congestion by applying rate limiting or back pressure at the network edge to protect the upper network layers from buffer overflow. CN is intended to provide lossless operation in end-to-end networks that consist of multiple tiers of cascaded layer 2 switches - the architecture typically used in larger data centers to support server interconnect, cluster interconnect and extensive SAN fabrics.

The third component is the IEEE 802.1Qaz Enhanced Transmission Selection (ETS) standard, which specifies advanced algorithms for the allocation of bandwidth among traffic classes, including the priority classes supported by 802.1Qbb and 802.1Qau.

DCB lossless Ethernet will play a key role in supporting Fibre Channel over Ethernet (FCoE) technology, which will allow the installed base of Fibre Channel storage devices and SANs to be accessed by Ethernet-attached servers with converged FCoE network adapters over a unified data center switching fabric. DCB will benefit not only block-level storage, but also all other types of loss- and delay-sensitive traffic. In the storage arena, DCB will improve network-attached storage (NAS) performance and make Internet Small Computer System Interface (iSCSI) SANs based on 10/40/100 gigabit Ethernet a more competitive alternative to 2/4/8Gbps Fibre Channel SANs.

It Won't Happen Overnight

So, the good news is that techniques now being developed and implemented will likely enable the convergence of the LAN and SAN. The bad news is that, for a variety of technological and cultural reasons, convergence tends to take a long time. If that seems counter-intuitive, just think back to earlier this decade and remember how many years were identified as being "The Year of VoIP."

Android: Enterprise Friend or Foe?

2012-01-16T15:59:22Z

]]>
Making Friends with IT

PIN/password lock, remote wipe and Exchange Active Sync (EAS) support have been around since Android 2.2. For some employers, these rudimentary security capabilities were enough - especially when paired with a self-encrypting messaging application such as Good for Enterprise or Nitrodesk Touchdown.

But Android has steadily expanded its Device Administration API, letting third-party applications - notably mobile device management (MDM) agents - set and query security policies from afar. Android 3 (Honeycomb) added more granular password policies and full device encryption, but these functions were supported by only a handful of new Android tablets. Android 4 brings these policies and others to new smartphones such as the Samsung Galaxy Nexus.

Android 4 also adds a new keychain API that applications can use to install and store user/device digital certificates and trusted enterprise certificate authorities. And it upgrades EAS to version 14, allowing IT to permit/deny Android Exchange Server access by certificate and device make/model and to disable potentially costly EAS synchronization while roaming.

Employers who want to move beyond secure messaging will appreciate Android 4's broader native IPsec and L2TP VPN clients, as well as its new VPN API, which supports third-party VPN clients (e.g., Authentec). To control ever-increasing mobile broadband usage, Android 4 can graph and alert or cap bandwidth consumption over defined periods.

Finally, employers wanting to develop enterprise applications will find Android relatively open, supporting IT-initiated local and over-the-air package installation ("side loading") independent of Google's Android Market. To deter malicious apps that might be installed from elsewhere, Android 4 adds Address Space Location Randomization (ASLR), which makes it harder for malware to successfully compromise Android devices.

Still Playing Catch-Up

While these administration and security improvements will increase enterprise tolerance for Android, the mobile OS platform still has a ways to go before catching up to Apple iOS, much less BlackBerry.

For starters, Android still lacks native MDM; users or IT personnel must install their chosen MDM agent before an Android smartphone or tablet can be centrally managed. And the user can always remove that agent - although doing so may trigger action to remove MDM-installed enterprise accounts and applications.

After installation, that MDM agent lets IT check for rooted devices, query/set policies (as of Android 4, including camera disablement) and query, install, update or remove applications. However, Android's permissions model requires that the user explicitly accept or cancel each application installed. This less-than- transparent experience results in users having to blindly accept everything - including potentially harmful public apps downloaded from the Android Market.

Why should this worry IT? Unlike Apple, with its tight-fisted control over its App Store, Google does not deeply vet Android Market apps, nor does it require that developers sign code with a Google-issued certificate. Instead, Google relies on the open-source community to raise red flags when malware appears on the Android Market. When risk warrants action, Google can remotely remove installed apps from infected devices, as it has done several times, starting with DroidDream Android trojans back in March 2011.

Closing the 'Trust Gap'

Due to this policing of the Android Market, most Android malware to date has been distributed through unofficial third-party markets. And alternative markets such as Amazon's and Verizon's are popping up to fill this "trust gap" with more rigorous reviews. Still, IT may be concerned about Market downloads and cautious about what's installed on Androids used for business.

To that end, requiring that new devices support full-device encryption, ASLR and no removable media can help limit Android malware's reach while avoiding data breaches due to lost or stolen devices. Some manufacturers, such as Samsung with its Samsung Approved for Enterprise (SAFE)-certified program, add proprietary device attributes to enable even more granular IT visibility and control.

Unfortunately, these advances don't yet apply to the vast majority of Android smartphones and tablets. It will take time for manufacturers and carriers to complete Android 4 upgrades for pre-2012 devices - and many will never be upgraded. For now, IT may be wise to more fully embrace the currently emerging generation of Android 4 devices, while still granting narrow or no business access by their older, less capable, higher-risk predecessors.

Deploying UC Apps: CPE or Cloud?

2012-01-13T13:28:00Z

A TechNote on Unified Communications
Gary Audin, Delphi, Inc.

]]> The advent of unified communications (UC) resurrects the question, "Should enterprises install their own customer premise equipment (CPE) or use outside services such as the cloud?" The answer depends not only on security, staffing and economics, but also on which approach is most effective at introducing enterprise users to the UC menu of features.

The most common approach to implementing enhanced communication functions has been through the use of an IP-based PBX on the enterprise's premises. Some enterprises have opted to subscribe to Centrex services (a form of telephony outsourcing) instead of owning and operating a PBX. But Centrex's feature list has been modest and not UC-specific.

Two Ways to Go

Two possible solutions are available to the enterprise for supporting UC:

A complete system purchased by the enterprise and located in its data center(s)
A remote service accessible through a private network or the Internet. Such a service can be called "hosted PBX," "virtual PBX," "hosted UC" or "communications as a service" (CaaS) in the cloud.

The first approach - buying, installing and maintaining a UC system - has a high first-year cost. This is mainly for software licenses, which may include bundled features that the enterprise does not necessarily want or need. However, if the UC system vendor offers per-feature licensing, the cost is typically much higher than when the bundled software package is purchased.

On the other hand, cloud-based/hosted UC services can be subscribed to on a feature-by-feature basis thereby avoiding a large license fee for unused features and giving the enterprise greater flexibility about which features it offers to which users. So far, most enterprises have implemented a few UC features and are monitoring their use to determine their benefits and associated return on investment (ROI).

IT and communication budget restraints can make a new on-premises UC solution too expensive. In fact, many enterprises prefer to avoid any new capital costs, making a cloud solution with little or no capital expenditure more attractive. The table compares cost and other traits of on-premises and cloud solutions.

Considering the Tradeoffs

The on-premises solution has potentially better security and does not require an Internet connection. The cloud service solution is probably cheaper and requires less staff time, but needs greater Internet bandwidth and poses more security issues. The two solutions are equal in terms of the number of physical phones needed and LAN operation requirements and expenses.

There is a booming market in cloud-based communication services, with more than 200 providers in the U.S. alone. The majority of these providers focus on VoIP and PBX services for small to medium-sized enterprises. However, the time has come for most enterprises to at least entertain the use of cloud-based UC services so they can determine whether there are cost or other benefits they might be missing.

Premises v. Cloud: Comparison Factors

Factor	On-Premises System	Cloud Service	Comparison
Real Estate Costs	System located at enterprise data center(s).	No data center real estate required except for network connection equipment to remote system.	Cloud service is cheaper.
Power and Cooling Costs	Responsibility of the enterprise.	Cost included in service fee except for on-prem network connection equipment.	Cloud service is cheaper.
Phone Costs	New IP phones and softphone licenses might be required.	New IP phones and softphone licenses might be required.	Solution costs are equal.
LAN Costs	Existing LAN(s) must carry voice and signaling traffic.	Existing LAN(s) must carry voice and signaling traffic.	Solution costs are equal.
PSTN Connections	Located at enterprise.	Located at provider.	Cloud solution controls PSTN access. If Internet failure occurs, no phone calls will be operational.
Internet Connections	Internet connections for remote teleworkers necessary when IP phones or softphones are deployed.	Internet connections for remote teleworkers and a data center Internet connection to access the cloud server needed.	Cloud has higher network cost because all calls must pass through Internet.
Security	Traffic remains within enterprise network except at teleworker locations, which will require firewalls.	Traffic traverses an external private network or the Internet. This increases security concerns, particularly for regulated enterprises.	Cloud solution poses greater security risk.
Disaster Recovery	At least two enterprise data centers with power and cooling backup are required.	Built into the service. WAN connections present possible reliability issue.	Slight advantage to the cloud.
Staffing	Part-time IT staff for data center operation and some administrative staff needed.	Only part-time enterprise WAN staff and some administrative staff needed.	Lower staffing requirement for cloud solution.

Virtual App Delivery Appliances Emerge

2012-01-11T19:43:09Z

A TechNote on The Next Generation
Jim Metzler
Distinguished Research Fellow and Co-Founder
Webtorials Analyst Division

]]>

Exhibit consistently adequate performance
Be easy to manage
Incorporate appropriate security levels
Be cost-effective

Toward this end, many IT organizations have implemented application delivery appliances such as WAN optimization controllers (WOCs) and application delivery controllers (ADCs). These appliances have typically been deployed as standalone hardware systems. But there's a growing trend to implement virtual application delivery appliances.

As explained in Webtorials' 2011 Application & Service Delivery Handbook, the term "virtual appliance" means different things to different people. For example, with some vendors' products (e.g., A10 Networks), it can mean that multiple ADCs can work together as a single large ADC. Other vendors (e.g., Citrix) can make a large ADC behave as if it were a number of smaller ADCs.

Why Do It With Software?

However, in most cases, "virtual appliance" refers to a software instance of the hardware appliance's functions. That software and its associated operating system run in one or more virtual machines (VMs) on top of a hypervisor - software that partitions a physical server into a number of virtual servers. In addition to WOCs and ADCs, virtual appliances can also include firewalls, intrusion detection/prevention systems, routers and performance monitoring solutions.

One factor driving virtual WOCs and ADCs in data centers is the fact that most IT organizations have virtualized at least some of their servers to maximize physical server utilization and decrease hardware, real estate and aggregate power and cooling costs. As a result, many enterprise data centers already have VMs that can be used to host a virtual WOC or a virtual ADC.

In a branch office, a suitably placed virtualized server could potentially host a virtual WOC appliance and other virtual appliances, forming what is sometimes referred to as a "branch office in a box." Alternatively, a router or WOC that supports VMs could also serve as the infrastructure foundation of the branch office. Virtual appliances can therefore support branch-office server consolidation strategies by enabling a single device (i.e., server, router, WOC) to perform multiple functions that traditionally have required multiple physical devices.

A compelling advantage of a virtualized application delivery appliance is that its acquisition cost can be notably less - sometimes by as much as a third - than that of a hardware-based appliance with identical functionality. In addition, a software-based client can potentially leverage the functionality provided by the hypervisor management system to provide a highly available system, eliminating the need to pay for a second backup appliance.

Another key advantage is that virtualized application delivery appliances help IT organizations implement a dynamic data center. For example, one challenge with migrating a VM between physical servers is replicating the VM's networking environment in its new location. Virtual appliances, unlike their physical counterparts, can be easily migrated along with the VM, making it easier to replicate the VM's networking environment at its new site.

What About Performance?

Conventional IT industry wisdom holds that a potential downside of virtual application delivery appliances is lower performance. A dedicated, purpose-built hardware appliance is generally thought to perform better than one in which software is ported to a generic piece of hardware, particularly if that hardware is supporting multiple applications.

However, conventional wisdom is often wrong. Some of the factors that enable a virtualized appliance to provide high performance include the following:

Moore's Law, which states that the price/performance of off-the-shelf computing devices doubles every 18 months
The deployment of multiple core processors, which further boosts the performance of off-the-shelf computing devices
The optimization of the software on which the virtual appliance is based

Mixed Opinions

The vendor community is of a mixed mind on the topic of virtual application delivery. Some ADC vendors, such as Riverbed and Citrix, are strong proponents; others, such as F5, are less bullish. Similarly, some WOC vendors, such as Silver Peak and Exinda, are strong backers of virtual WOCs, while others, such as Riverbed, are not.

I will moderate a session at the Interop Las Vegas Conference and Expo, to be held at the Mandalay Bay May 6 -10, 2012, titled, "Is this the End of Physical Appliances?" The session, to be held Tuesday, May 8 at 2:30 p.m., will identify the pros and cons of virtual appliances and discuss implementation considerations. Please attend, learn more about this important topic and provide your input.

8 Pitfalls to Avoid When Managing Mobile Apps

2012-01-09T16:53:04Z

A TechNote on Wireless and Mobility
Joanie M. Wexler
Technology Analyst/Editor
Editorial Director, TechNotes

]]>
Not entirely. Mobile environments present some unique challenges that call for new types of tools. For example, the uptick in the number of users choosing their own wireless devices has led to a lack of uniformity across mobile operating systems accessing the enterprise network. This means that, unlike in the PC era, IT must keep up with software versions and patches for several different platforms. But how?

As you've likely heard, there are emerging automated mobile tools to deal with the complexity of this situation. Most are policy-based and fall under the closely related categories of mobile device management (MDM), mobile application management (MAM) and enterprise app store (EAS) solutions.

These tools are key. But it also helps to know about some common mistakes to avoid as you deploy them.

Dodging the 'Don'ts'

There's a learning curve to using MDM, MAM and EAS tools successfully. Compiled with some assistance from wireless consultancy Core Competence and MDM and expense management company Tangoe, the list below suggests several pitfalls to avoid:

1. Don't overlook each app's system requirements on different devices. Be sure the mobile app you are deploying will peacefully coexist with mobile apps already installed. This involves making sure you account for the OS version, memory constraints and all other system resource requirements before deployment. Despite the inconsistent nature of mobile platforms in use, multiplatform MDM client software installed on employee devices (as well as some mobile OSs) will report memory and storage statistics to your MDM server. Use this data to make the necessary system resource checks before rolling out software to each device.

2. Don't assume that tools and OSs work the same way in mobile environments as they do on the desktop. For example, when you push out a mobile software update, you can't take for granted that the newer version will simply overwrite the older version. Some platforms require that you remove the older version before installing the newer one. Also note that some mobile OSs, such as Apple iOS and Google Android, operate in more of an "app pull" than an "app push" model, requiring some level of user involvement to allow an app's installation.

3. Don't disregard a mobile device's network status. If you are delivering new or updated application software to devices over the air, it's probably not very thrifty to do so when devices are in roaming mode. Roaming occurs when users are outside their primary carrier's network coverage area and are automatically switched onto the network of one of the carrier's partners. Roaming incurs carrier-to-carrier settlement and usage charges, which can be shockingly hefty when employees travel abroad. It's best to push the software out via an approved Wi-Fi access point (for cost, security and capacity reasons) or to an otherwise local device on a flat-rate or pooled data plan.

4. Don't forget to verify app installation. Some updates might fail because a user has his device turned off, for example. Provide a retry/error resolution process for those that do fail.

5. Don't forget to audit installed apps for non-compliance with your internal or governance-mandated best practices and provide a process for bringing them into compliance.

6. Don't rely on users to configure apps. Instead, automate the distribution of settings and licenses as well as software and updates.

7. Don't depend on public/consumer app stores for custom app distribution. If you build an internal enterprise app that connects to the back-end systems behind your firewall, you probably don't want to put it in a consumer app store, if only for security reasons. Also, IT usually can't distribute public apps the same way it distributes enterprise apps because of mobile OS limitations and vendor rules surrounding app distribution and licensing.

8. Don't assume your MDM system supports all your platforms. Not all MDM systems support all mobile OSs, so it's important to check that the system you select supports the platforms in your environment. Employees bringing their own devices makes this difficult, but it's still a good idea to identify what you can and cannot support.

Desktop Video vs. Telepresence: Which, When and Why?

2011-12-29T16:11:59Z

A TechNote on Unified Communications
Gary Audin, Delphi, Inc.

]]>
Why Video Communication?

Adding a picture (video) to a communication connection can enhance almost any user experience. Video conferencing and telepresence can boost productivity and reduce costs by allowing employees and customers to travel less. They can also reduce workplace stress by making the conversation more comfortable and relaxed for the participants, improve customer relationships, support remote training, and even reduce the time-to-market for new products and services by fostering faster/better decision making.

Videoconferencing emerged in the 1990s on ISDN and frame relay network connections. The advent of IP networking significantly expanded the number of potential users and increased available bandwidth, thereby improving the video quality. What was once a limited animation picture is now displayed in real time and full motion. Video and voice quality have risen to the point that participants may forget they are on a long-distance conference connection rather than in the same room.

Technology Choices

Videoconferencing can be implemented on a PC, laptop, tablet or mobile phone with varying degrees of picture resolution (not TV quality but usually good enough) and voice quality. It can be implemented as an application on an IP phone. There are no special room requirements. The participants see and speak to each other, but it is obvious that they are in separate locations.
Telepresence delivers a virtual experience where the participants appear to be in the same room. The screens display such high-resolution pictures that participants can forget that they are at remote locations. Many participants can easily be part of the same telepresence connection in the same room. Two or more remote conference rooms, identically furnished and decorated, are seamlessly connected as if there were only one room. The participants can be displayed on the screens in normal size, creating the perception that everyone is in the same room.
Personal telepresence with HD videoconferencing is essentially a high-resolution video connection that is designed to reduce the endpoint costs. Participants are not as immersed as in true telepresence, nor are the room arrangements quite as restricted. This compromise solution is best suited to a small number of participants, probably no more than two per endpoint.

Making the Technology Decision

Videoconferencing is growing rapidly, especially as an application on existing devices. The enterprise can start small, with an application as simple as Skype and its limited-performance video calls. This will help to determine if video conferencing is of real value or just a technology to be used casually.

Depending on work environment and budget, the enterprise can implement many levels of videoconferencing and telepresence. Some enterprises have widely dispersed executives and experts who need to communicate frequently and for whom a conference phone call is not adequate. Telepresence not only improves the communication and reduces travel costs, but it can also cement better relationships and even reduce the stresses typically encountered with less immersive communication media.

Telepresence is expensive: rooms must be dedicated to the task and outfitted with appropriate equipment. There's an associated network capacity cost, too. Telepresence connections can consume 2Mbps to 10Mbps or more per endpoint for a two-site connection. Each additional participant will add 1Mbps to 5Mbps or more to the bandwidth requirements at each conferencing location.

To justify its use, telepresence must deliver high value and be used with some frequency. Videoconferencing is cheaper and better suited to the desktop. Whatever the choice, the enterprise needs to experiment with multiple forms of video communication and develop a sound return on investment (ROI) for the selected solution.

A useful set of references is the Telepresence Option Series, available at Webtorials.

OpenFlow and SDNs Raise Many Questions

2011-12-28T17:16:19Z

A TechNote on The Next Generation
Jim Metzler
Distinguished Research Fellow and Co-Founder
Webtorials Analyst Division

]]>
Potential for Increased Flexibility

Switches and routers have two fundamental components: the control plane and the data plane. The control plane provides the intelligence to make decisions, while the data plane provides the functionality to forward packets. In an SDN, the network device's control plane runs in software on commodity servers separate from the network devices. In addition, the data plane becomes more programmable.

The hope is that virtualized, programmable networks will make it significantly easier to introduce new functionality into the network. In fact, many of the concepts that underlie an SDN are not new; Asynchronous Transfer Mode (ATM) LAN Emulation, for example, was an earlier attempt to separate the control and data planes.

A previous TechNote discussed alternatives to the Spanning Tree Protocol, which has been used for decades to eliminate data-forwarding loops in bridged Ethernet LANs. These alternative protocols include shortest path bridging (SPB) and Transparent Interconnection of Lots of Links (TRILL). Because the control plane of an SDN has a global view of the network topology, it allows the SDN to avoid loops without having to resort to protocols such as TRILL or SPB.

The OpenFlow application programming interface (API) can function as a "network hypervisor" by providing a common instruction interface between the network operating system (NOS) and the packet-forwarding hardware. This abstraction layer allows OpenFlow-enabled switches from different vendors to be mixed and matched without impacting the NOS. The OpenFlow Switch Consortium had maintained the OpenFlow specification until recently, when the Open Networking Foundation announced that it would assume this responsibility.

Building an SDN with OpenFlow

There are two requirements for building an SDN with OpenFlow:

A NOS that supports OpenFlow. This NOS could be a modification of an existing proprietary NOS or possibly an open-source NOS.
Packet-forwarding hardware that supports OpenFlow. In principle, the SDN could be based on a physical network built with OpenFlow switches from a number of different vendors.

A major potential benefit of an SDN with OpenFlow is that multiple independent virtual networks can share a common physical infrastructure. Virtual networks would be based on segmenting flows. Within OpenFlow, flows are defined using a 10-tuple of header fields including Ethernet source and destination address (SA/DA), IP SA/DA, TCP/UDP ports, and VLAN ID. This could be used to provide enhanced security via firewall-style granular control of traffic flows within virtual networks.

In a recent Webtorials discussion about OpenFlow, six leading data center LAN switch vendors were asked if OpenFlow would relegate switches and routers to being merely "dumb" forwarding devices and move all network intelligence to be hosted in commodity servers. Not surprisingly, none of the six vendors thought that outcome was likely.

The reality, though, is that it is much too soon to tell. Despite all the interest in SDNs and OpenFlow, networks implementing these two technologies have not yet been widely deployed. As a result, it is impossible to say whether routing decisions, for example, can be handled successfully in a centralized server or if that would introduce too much delay, requiring that routing continue to take place inside the routers.

While OpenFlow is the approach that currently has the greatest momentum, it is not the only way to implement an SDN. A half-day workshop on SDN and OpenFlow will examine the alternatives and issues at the Interop Las Vegas Conference and Expo, to be held at the Mandalay Bay May 6-10, 2012. I will co-moderate the session on Monday, May 7, along with Mike Fratto of Network Computing. Please attend, learn more about this important topic and provide your input.

Does iOS 5 Land IT Back in the Driver's Seat?

2011-12-27T16:10:14Z

]]>
The answer is a qualified yes. The new version further expands IT control over mobile devices. Let's take a look at some of those new iOS 5 capabilities.

Inching Away from iTunes...

Until now, initializing a new iPhone or iPad meant a USB connection to iTunes on a Mac or PC. Worse, each device could sync with just one instance of iTunes (i.e., authorized computer). These restrictions impeded bulk activation and forced IT to rely on iTunes synchronization with each worker's own home or office computer.

Thankfully, any iPhone or iPad with Internet access can now be activated over the air, bypassing iTunes. Alternatively, IT can now run iTunes in "activation only" mode to initialize devices via USB, skipping user-owned music/photo/video synchronization.

While IT can still allow iTunes synchronization, it can now use Active Directory Group Policy Objects (GPOs) to install iTunes "silently" (without user assistance or awareness) onto employee PCs with or without Apple Update and Apple's Bonjour LAN discovery and sharing service. IT can also set registry keys to restrict iTunes. This allows IT, for example, to decide when to enable iOS updates, disable iTunes LAN sharing or block backup onto a user's office computer.

...and Toward iCloud

The reason for Apple's decreased dependency on iTunes? Its iCloud hosting and synchronization service. As Webtorials editorial director Joanie Wexler wrote in an October TechNote, "iCloud to Test Wi-Fi Performance Mettle," iOS 5 recast Apple's MobileMe into a cloud service that auto-syncs each "iDevice" over Wi-Fi. iCloud can sync user contacts and calendars and map a lost device's location. But iCloud takes on several tasks previously performed only by iTunes, including media synchronization, application maintenance and backup.

For enterprises, iCloud is a double-edged sword: a turnkey platform to help meet business needs, but another external service to control and police for leaks. For example:

With iOS 5 APIs, applications can save documents and internal state (key values) to iCloud storage and make them accessible to all mobile and desktop devices. These APIs let enterprises develop integrated mobility applications without worrying about cross-device synchronization or backup - but only where iCloud satisfies data security and availability requirements.
To that end, iCloud encrypts synchronized content - documents, mail, contacts, calendars, bookmarks, reminders, notes, streamed photos, device location, backup files - using Secure Sockets Layer (SSL) over the air and Advanced Encryption Standard (AES) at rest. However, iCloud access is authenticated by tokens associated with each user's iCloud credentials. Researchers have already raised concerns about this scheme, but it will take time for the security industry to assess its strengths and vulnerabilities.

Augmented App Management

Apple also continues to beef up IT-controlled application delivery: enterprises can now buy public apps from the App Store in bulk.

With the iOS 5 Volume Purchase Program, IT creates an account to buy apps on-line and receives redemption codes to distribute to employees via email, Short Message Service (SMS) or Mobile Device Management (MDM). Users must still visit the App Store to download apps, but no longer submit payment. This eliminates costly and confusing reimbursement programs.

Extended Config Profiles and APIs

In the near term, enterprises are likely to be concerned with controlling iCloud use. iOS 5 enables some control by extending configuration profiles and native MDM APIs introduced in iOS 4.

Configuration profiles are optionally encrypted attribute lists for iDevice administration. Apple's Configuration Utility can be used to manually generate and install profiles, or profiles can be administered and auto-installed over the air using a third-party enterprise MDM such as AirWatch or Fiberlink MaaS360.

iOS 5 profile attributes can enable/disable iCloud backup, document and key value synchronization, and photo streaming. They can also stop users from downloading apps or music from Apple. However, these attributes do not yet offer the granular control that enterprise IT may want. For example:

Users can selectively decide whether to synchronize mail and/or contacts and/or calendars, etc., to iCloud. But for IT, iCloud synchronization is all or nothing.
Users can decide whether to sync to iTunes over Wi-Fi. But IT must resort to blocking ports/URLs to control synchronization on the office WLAN.

In short, iOS 5 profiles leave plenty of room for iOS 6 enhanced IT control over both iCloud and iTunes.

Making a Business Case for UC

2011-12-22T14:04:40Z

A TechNote on Unified Communications
Gary Audin, Delphi, Inc.

]]>
Deploying UC will impact IT applications, communications, users and customers. Before the enterprise approves the project and releases the budget for embarking on a UC implementation, IT has to develop a compelling business case and justify the associated expenditure.

The Value of UC

Unified communications is a collection of capabilities that can benefit and improve many aspects of an enterprise. A successful UC implementation can lead to benefits in some or all of the following areas:

Business - Increased revenue and profit, a more competitive enterprise, shorter time to collaboration, richer communication, improved customer service, reduced travel expenses and improved response to disasters and service outages
Mobility - Improved remote collaboration, reduced travel and commuting time and lower mobile usage costs
Users - Increased productivity, lower cost-per-unit sales, shorter communication lag, reduced communications tag and streamlined workflows and business processes
IT - Lowered costs and reduced user support efforts

Why Write a Business Case?

The cost of a UC implementation can be relatively small (e.g., if a single function such as videoconferencing is implemented) or quite large (if the majority of UC functions are deployed in a single project). The greater the expense, of course, the more closely executive management will want to examine the proposed budget. Though most IT managers recognize the need for a business case, they do not always spend enough time writing a thorough, well-thought-out document. Yet the better the plan, the more likely it is to win approval.

There are three roles for the business case:

Forcing IT to consider what has been implemented and how the UC solution will benefit the enterprise
Verifying and substantiating how UC will meet business goals
Presenting the UC solution in a form that can appeal to different audiences in the enterprise (financial, marketing, technical, etc.)

5 Key Components

Executives typically look for a 12- to 18-month payback on an IT investment - any longer and the perceived risks rise while the benefits appear less solid. The business case should contain five components if it is to be considered worth analyzing and approving:

Return On Investment (ROI) calculates implementation and operation costs and determines the time at which UC should start to deliver the value that pays for the investment.
Total Cost of Ownership (TCO) includes all costs to own, implement, operate and maintain the UC solution over a specific time period (e.g., three to five years; the monthly bill).
Net Present Value (NPV) is a financial figure that measures the investment in terms of future cash flows minus the initial investment. NPV brings in the time value of the money for a long-term project. This is where the CFO assists in formulating the business case.
Soft Dollar Savings can be hard to quantify. Implementing UC may help reduce employee turnover, reduce workplace stress, create stronger customer loyalty, increase market share and improve customer loyalty.
Other Costs include expenses that can occur in related technologies and staff work such as network upgrades, expanding management tools and systems, staff training and improved security measures.

The business case needs to appeal to many individuals and departments across the enterprise. The broader the business case coverage, and the more thorough the presentation and analysis, the more likely the migration to UC will be approved.

Cloud Computing Causes IT Culture Shock

2011-12-21T13:49:35Z

A TechNote on The Next Generation
Jim Metzler
Distinguished Research Fellow and Co-Founder
Webtorials Analyst Division

]]>
Cloud Computing and 'Good Enough' Service Delivery

One of the cultural shifts associated with cloud computing is a direct result of the goal of cloud computing: to enable IT organizations to achieve a dramatic improvement in the cost-effective, elastic provisioning of IT services that are "good enough." To understand the concept behind "good enough," consider just the availability of an IT service. In cases where the service is business-critical, good enough could mean five or six 9s of availability. However, in many other cases, good enough has the same meaning as "best effort" - typically two or three 9s of availability. An approach that provides two or three 9s of availability is acceptable when the IT service isn't business-critical, and it is significantly less expensive than one offering higher availability.

To put this cultural shift into perspective, it is important to realize that it has been implicit in the traditional IT culture to implement ongoing enhancements to make the network - and the IT services delivered over the network - increasingly resilient. The adoption of cloud computing changes all that, and in some instances it becomes acceptable for the first time that IT services be delivered on a best-effort basis. A clear indication of that change is the success of Salesforce.com, whose three million customers use the company's solutions to support critical sales processes. Yet despite the importance of this application, Salesforce.com will virtually never give a customer an availability guarantee; and since the application typically is accessed over the Internet, it doesn't come with an end-to-end performance guarantee.

New Role for IT: Provider vs. Broker

Another cultural shift associated with the adoption of cloud computing is that an IT organization becomes less a provider of IT services and more a broker of IT services. Traditionally, the IT organization is the primary provider of IT services. Part of the challenge of this role is that sometimes the IT organization can't meet the needs of the business units in a timely fashion. In the past, business unit managers have dealt with this lack of support by creating their own "shadow" IT organizations made up of business unit staff members who provide the IT services unavailable from the corporate IT department.

Today, public cloud providers often play the role of a shadow IT organization by providing a company's business unit managers with services or functions that they either can't get from their own IT organization or can't get in a timely manner. In some instances, IT is in a position to stop the non-sanctioned use of public cloud computing once it is discovered. There may be good reason do so.

One example is in cases where using a public cloud service causes the company to be out of compliance with certain regulations. Often, however, corporate IT might not even be aware that one or more business unit managers have taken it upon themselves to use an outside cloud service.

Trying to prevent business unit managers from acquiring public cloud services might not be the best use of an IT organization's resources. A better role for IT is to evolve from being the primary provider of IT services to providing some IT services, such as those that involve highly sensitive data, but acting as a broker between the company's business unit managers and cloud computing service providers for other services. Those other services might be those for which there is a defined short-term need or that can be acquired more cheaply from a third party.

In addition to handling contract negotiations, the IT organization can add value by ensuring that the acquired application or service doesn't create any compliance issues, can be integrated with other applications as needed, can scale, is cost-effective and can be easily managed.