As Wi-Fi continues to be the primary mode of access, enterprise Unified Communication(UC) applications usage is increasing with smartphones, tablets and laptops.
Customers are asking, is there anything I can do to prioritize Jabber or Lync traffic over others or even identify how much of the traffic is really collaboration traffic vs. other types of media. The recently introduced Wireless Release 7.6 enhances the ability to classify Microsoft Lync 2013 and Jabber with Cisco WLAN Infrastructure.
In the first blog about Application Visibility and Control over Cisco WLAN, I captured what is AVC and the capabilities included in the release 7.4. In a subsequent blog, I had captured a success story about a customer who benefited from the reliability by deprioritizing scavenger level applications as well as captured highlights of the enhancements in release 7.5. This blog captures how the release 7.6 allows popular collaboration applications to be accurately classified and prioritized as well as provides a teaser to some of the innovations that can be expected in the future.
What exact capabilities AireOS 7.6 provide ?
The protocol pack 6.3 introduced in AireOS 7.6 allows you to identify and prioritize not just Jabber but also sub-classify Cisco Jabber Audio, Cisco Jabber IM and Cisco Jabber Video. Customers may want to prioritize the Cisco Jabber Audio as the highest priority while the others may be lower priority. Similarly you can classify not just Microsoft Lync but also Microsoft Lync Audio, rtcp and Microsoft Lync Video and thereby prioritize them separately. Read More »
Tags: aireOS, App, Apple, application, AVC, beta code, certification, classify, collaboration, communication, control, controller, dropbox, ESPN, infrastructure, innovation, jabber, lync, media, Microsoft, NBAR, NBAR2, Outlook, packet size, protocol, protocol pack, qq, release 7.6, rtcp, traffic, UC&C, unified communications, user, video, visibility, webgui, whatsapp, wi-fi, wifi, wireless, wlan, WLC
Today is the final day of a very busy and successful Cisco Live Milan 2014. Read my initial observations from the event earlier this week.
As the event draws to a close, lets look at some of the location analytics available via Cisco’s Connected Mobile Experiences solution (CMX) and perhaps try to answer some of the following questions about the event.
For this I will just focus on the World of Solutions Show floor -- approximately 800,000 sq feet in size, and containing all the Cisco Booths and the partner displays.
- How many people actually visited the world of solutions?
- How many people did the different Cisco Booths attract?
- Where was the busiest part of the show floor?
These and other insights can be derived from looking at the business intelligence that emerges from CMX. Read More »
Tags: #CLEUR, analytics, business intelligence, ciscolive, cmx, controller, crowding, customer, data, deployment, device, dwell time, early adopter, event, heat map, insight, lbs, location, location based services, location services, location-based, mobile, mobility, mse, network, operation, services, solution, technology, visitor, wi-fi, wi-fi location, wifi, wifi location, wireless, world of solutions, wos
Current differences in app development on devices and controllers disappear. Devices and controllers will share a common programming environment – offering a unified development and deployment experience.
While SDN is moving from concept to reality, we notice that many deployments which focus on creating new network features interpret the role of the “controller” very pragmatically. In these deployments, the controller is not used as an independent layer of software which abstracts the entire underlying infrastructure as in the traditional view of SDN (see for example ONF’s SDN Definition). The pragmatic approach to network programming simply extends the distributed development environment of the network devices using a set of qualities offered by the controller. Developers move those components of their distributed apps to the controller that benefit from the logical centralization or the enhanced resources (CPU, memory) that a controller typically offers while keeping other components on the network devices. Example use cases fall into the categories of distributed network analytics, DDoS thread mitigation, or routing optimization based on performance measurements. What does this mean for our development environment?
Read More »
Tags: controller, Network programmability, onePK, SDN
Now that OpenDaylight has arrived, it’s time to explain why I made the Open Source choices eventually embraced by its Founders and the community at large. One doesn’t often see such leaders as Cisco, IBM, Intel, HP, Juniper, RedHat, VMWare, NEC, Microsoft and others agree, share and collaborate on such key technologies, let alone the latter engaging in a Linux Foundation based community (some thought hell will freeze over before that would ever happen, though it got pretty cold at times last Spring).
For those of you not familiar with OpenDaylight (see “Meet Me On The Equinox”, not a homage to Death Cab for Cutie or my Transylvanian homeland), IBM and Cisco have actually started this with an amazing set of partners, nearly that ephemeral Equinox this year (~11am, March 20th) though we couldn’t quite brag about it until all our partners saw the daylight, which by now, we’re hoping everyone does. It was hard not to talk about all this as we saw those half baked, speculative stories before the Equinox – amazing how information flew, distorted as it were, but it did; I wish source code would be that “rapid”, we’d all be so much better for it…
The Open Source model for OpenDaylight is simple, it has only two parts: the community is hosted in the Linux Foundation and the license is Eclipse. The details are neatly captured in a white paper we wrote and published in the Linux Foundation. Dan Frye, my friend and fellow counterpart at IBM and I came up with the main points after two short meetings. It would have been one, but when you work for such giants as our parent companies and soon to be OpenDaylight partners, one has to spend a little more time getting everyone to see the daylight. It boils down to two things, which I am convinced are the quintessential elements of any successful open source project.
1) Community. Why? Because it trumps everything: code, money and everything else. A poor community with great code equals failure (plenty of examples of that). A great community with poor (or any) code equals success (plenty of examples of that too). Why? Because open source equals collaboration, of the highest kind: I share with you, and you with me, whatever I have, I contribute my time, my energy, my intellectual property, my reputation, etc.. And ultimately it becomes “ours”. And the next generation’s. Open Source is not a technology; it’s a development model. With more than 10 million open source developers world wide, it happens to be based on collaboration on a scale and diversity that humanity has never experienced before. Just think about what made this possible and the role some of the OpenDaylight partners have already played in it since the dawn of the Internet. Dan Frye and I agreed that the Linux Kernel community is the best in the world and so we picked the closest thing to it to model and support ours, the Linux Foundation.
2) Fragmentation, or anti-fragmentation, actually. Why? The biggest challenge of any open source project is how to avoid fragmentation (the opposite of collaboration). Just ask Andy Rubin and the Android guys what they fear the most. Just ask any open source project’s contributors, copyright holders, or high priests, how much they appreciate an open source parasite that won’t give back. Though we would have liked to go deeper, we settled on Eclipse, largely because of the actual language and technology we dealt with in the OpenDaylight Controller: most, if not all the initial code is Java, and though some are worried about that, I’m sure Jim Gosling is proud (btw, I’m not sure the Controller has to stay that way, I actually agree with Amin Vahdat), but we had to start somewhere. Plus having a more friendly language NB (northbound, as in the applications run on top of the Controller) is such a cool thing, we think that the #1 open source (Eclipse) and the #1 commercial (Microsoft) IDE’s are going to be very good to it, so why not? There are more reasons that pointed in the Eclipse direction, and other reasons for such wonderful alternatives (as APL or MPL, perhaps the subject of another post, some day). But when it comes to understanding the virtues of them all, no one understands them better than the amazing founders of these license models, most of them from IBM, of course (I wish they did that when I was there).
What happened between the Equinox and Solstice is a fascinating saga within the OpenDaylight community which I think played its course in the spirit of total and complete openness, inclusion, diversity, respect of the individual and the community, and most of all, that code rules – we do believe in running code and community consensus. I tip my hat to all my fellow colleagues that learned these two things along the way, the enormous talent at the Eclipse and Linux Foundation that helped us launch, and even the analysts who tried (and did incredibly well at times) to speculate the secret reasons why these partners came up with the model we did: there is no secret at all, my friends, we’re simply creating a community that is truly open, diverse, inclusive, and never fragmented. Just like a big, happy family. Welcome to OpenDaylight, we hope you’ll stay!
Tags: Android, apache, Cisco, community, controller, Eclipse, Fragmentation, IDE, java, Linux Foundation, Linux Kernel, ONE, onePK, open source, open source model, opendaylight, SDN
With the prevalence of mobile devices connecting people and things today, we are seeing a base expectation for uncompromised wireless connectivity. There is no doubt that the trend for high performance, pervasive wireless is on the rise and will continue for the foreseeable future. We at Cisco strive to help organizations get ahead of these trends with solutions that can be deployed with confidence today. That’s why I am proud to announce the latest Cisco Wireless Release 7.5, the third feature-rich release we’ve had in the last 12 months.
Release 7.5 enables mission critical wireless deployments with sub-second stateful failover for wireless clients, wire-like Gigabit performance with the 802.11ac Module, and a bevy of other features.
Key Features in 7.5:
Tags: 7.5, access point, bonjour services, Cisco, controller, feature, High Availability, Mission Critical, mse, release, wi-fi, wifi, wireless, wlan