Companies such as Cisco, Arista Networks, HP/3Com, Force10, Voltaire, Extreme, Brocade, Juniper et al have announced network fabrics for data centers with five thousand and more servers with and without storage enablement. Juniper talks of a one-tier fabric through their Project Stratus work with IBM to be available some time in the future. Brocade recently introduced its Brocade One, which is a converged data center fabric. Extreme Networks launched its DirectAttachTM that eliminates virtual plus blade switch layers. HP has FlexFabric, a virtualized fabric for the data center. Cisco launched its FabricPath Switching System or FSS for the Nexus 7000 that enables massive scale of a two-tier fabric.

In this Lippis Report Research Note, we review the architectural attributes of two tier network fabrics.

The IT industry is at an inflection point as service delivery is becoming more and more centralized thanks to data center consolidation, virtualization, cloud and mobile computing. It is estimated that a third of all IT spend is concentrated in the data center, and this trend is only building thanks to favorable economics, motivating IT business leaders to centralize IT delivery.

The impact of this trend is more and more dense data centers made up of servers in the thousands to tens of thousands and higher. It is at the scale of 5,000 plus servers that a new network fabric is required for high-end data centers. High-end data center design is challenged with increasing complexity, the need for greater workload mobility and reduced energy consumption. Traffic patterns have also shifted significantly, from primarily client-server or as commonly referred to as north-to-south flows, to a combination of client-server and server-server or east-to-west plus north-to-south streams. These shifts have wreaked havoc on application response time and end user experience, since the network is not designed for these Brownian motion type flows.

The main requirements for high-end data center network fabric are low latency, large flat layer 2 domains to enable workload mobility, low power consumption, simplicity of design and significant bandwidth. Storage enablement, meaning consolidated I/O or virtualized I/O, is a growing priority and a new fabric that can support FiberChannel over Ethernet, iSCSI over Ethernet, iWARP over Ethernet or Infiniband over Ethernet, is a major plus. One salient observation is that it’s pretty clear that Ethernet is the network fabric of choice, as it is the only network protocol that enjoys continual innovation such as TRILL, Data Center Bridging, IEEE’s 802.1AQ, link aggregation, multi-pathing, and as recently ratified by the IEEE 40 Gbs and 100 Gbs speeds.

With the above requirements in mind, let us review data center network design options.

Three Tier Data Center Fabric

A three-tier network architecture is the dominant structure in data centers today and will likely continue as the optimal design for many networks. For most network architects and administrators, this type of design provides the best balance of asset utilization, layer 3 routing for segmentation, scaling and services, plus efficient physical design for cabling and fiber runs. By three tiers we mean, access switches/Top-of-Rack (ToR) switches, or modular/End-of-Row (EoR) switches that connect to servers and IP based storage. These access switches are connected via Ethernet to aggregation switches. The aggregation switches are connected into a set of core switches or routers that forward traffic flows from servers to an intranet and internet, and between the aggregation switches. It’s common in this structure to over-subscribe bandwidth in the access tier, and to a lesser degree, in the aggregation tier, which can increase latency and reduce performance. Inherent in this structure is the placement of layer 2 versus layer 3 forwarding that is Virtual Local Area Networking or VLANs and IP routing. Also common, is that VLANs are constructed within access and aggregation switches, while layer 3 capabilities in the aggregation or core switches route between them.

But within the high-end data center market, where the number of servers is in the thousands to tens of thousands plus and where north-south plus east-west traffic is significant, is where a new structure is needed. It is within these data centers where applications need a single layer 2 domain.

Two-tiers of network fabric

A two-tier fabric is designed with two kinds of switches: one that connects servers, and the second that connect switches creating a non-blocking, low latency fabric. In short, there are server facing and fabric facing switches. We use the terms ‘leaf’ switch to denote server facing or connecting switches and ‘spine’ to denote fabric facing or switches that connect leaf switches into the fabric. Together, leaf and spine switches create the fabric.

Many IT leaders in Global 2000 firms will have deployed both two and three tier network structure, as different deployment models are used for different applications. For these leaders, a network equipment supplier that possesses product architecture flexibility, meaning an end-to-end product solution that accommodates tier two and three fabrics would be advantageous. This flexibility is found in product that supports layer 2 and layer 3 forwarding, as well as, a variety of line cards to offer design options.

A common network Operating System (OS) of products configured for two and three tier structure is important as IT operations gain efficiency to manage fabrics, as configuration and management are consistent. In addition, a common network OS offers rapid absorption of innovation to IT operations, as new OS features are available at the same time to all fabrics. The benefit of using a common product set to build tier two or three fabrics offers value around operational efficiency, training, sparing and ease of evolution between fabric deployments. In short, the network fabric needs to be simple and general purpose versus purpose built, which a common set of products creating tier two or three fabrics offer.

A Unified/Converged Fabric

The concept of a unified fabric is to virtualize data center resources and connect them through a high bandwidth network that is very scalable, high performance and enables the convergence of multiple protocols onto a single physical network. These IT resources are compute, storage and applications, which are connected via a network fabric. In short, the network is the unified fabric and the network is Ethernet.

The industry tends to focus on storage transport over Ethernet as the main concept behind a unified/converged fabric with technologies such as Fiber Channel over Ethernet or FCoE, iSCSI over Ethernet, iWARP over Ethernet and even Infiniband over Ethernet. But this is a narrow view of a unified/converged fabric which is being expanded, thanks to continual innovation of Ethernet by the vendor community and standards organizations such as the IEEE and IETF.

Ethernet innovations such as FCoE, Data Center Bridging or DCB, IETF’s Transparent Interconnection of Lots of Links or TRILL, CEE or Converged Enhanced Ethernet, link aggregation, IEEE’s 802.1AQ have enhanced Ethernet networking to support a wide range of new data center fabric design options. In addition to these protocol enhancements, the IEEE has ratified its work on defining 40Gb and 100Gb Ethernet, significantly increasing Ethernet’s ability to scale bandwidth. To demonstrate how Ethernet is evolving to be the unified fabric for high-end data centers, we explore Cisco’s new FabricPath Switching System innovation in this white paper.

The decision to implement a two or three tier network structure comes down to scale. For high-end data centers, a two-tier structure meets the requirements of low latency, movable workloads, scale, simplicity, etc. Many global 2000 concerns will have deployed both a two and three tier network fabric for their high end and less dense data centers.

When shopping for network equipment to construct two and three tier network fabrics, look for suppliers that support both rich Layer 3 routing services and scalable Layer 2 Ethernet capabilities to ensure choice and flexibility of three tier and scalable two tier fabric implementations. Such suppliers offer products that can be configured in multiple use cases and topologies where modules are inter-changeable, skills transferable and operations common between both fabric approaches.

But make no mistake about it, it’s a two-tier network fabric that IT business leaders and data center architects have gravitated toward for high performance computing, cloud scale data centers and just plain high end data centers of 5,000 and above servers.

ShareThis

A typical “non-virtualized” data center has three network layers, Top-of-Rack, End-of-Row and Core switches. But virtualized infrastructure adds two additional layers; the virtual switch and blade switch, raising the number of tiers from 3 to 5. This significantly increases latency plus the number of network elements within the data center resulting in increased data center management complexity.

Extreme Networks® Direct AttachTM eliminates the virtual switch layer, simplifying the network and improving performance. Extreme Networks high density BlackDiamond® 8800 series switches with 8900-series modules further enable data center simplification by utilizing high density blades and cabling to eliminate the blade switch, thereby reducing the number of tiers in the data center from 5 to 3.

Find out how by downloading this white paper:

Get the White Paper

ShareThis

Sure networking has increased from a bandwidth point of view and the IETF has added new protocols and network services, but it hasn’t kept up with compute innovation. As data centers pack more compute power and operating systems (OS) per physical server, thanks to virtualization, the need to move containers of OS plus applications and data around have sky rocked. In addition, traffic patterns have shifted tremendously as client-server or north-south flows are layered on top of server-server or east-west flows. And yes, there are new networking approaches being offered by vendors and standard organizations such as Cisco’s FlexPath, Juniper’s Stratus, Brocades VCS, Extreme’s Direct Attach, Force 10’s Open Automation, Arista’s Multi-Chassis Link Aggregation, BLADE’s Unified FabricArchitecture, the IETF’s TRILL and LISP and IEEE’s 802.1AQ, but these may be short term solutions to a much bigger networking problem.

Computing has always driven network design as mainframes drove SNA and analog multi-point wide area networks (WANs) during the ’70s. Mini-computers drove peer-to-peer networking protocols like DecNet, OSI and TCP/IP in the ’80s. Client-Server computing drove LANs and TCP into the mainstream in the early ’90s. The Web drove the internet in the 2000s and now server virtualization and cloud computing is once again changing fundamental networking requirements to make them more flexible.

The rigid label is a powerful one as it creates frustration by not addressing or enabling new business processes. Every time a network protocol or architecture was labeled as too rigid it was replaced and in the process a new market emerged on the scale of tens of billions of dollars. SNA was labeled as too rigid to support peer-to-peer networking. The T1 multiplexer market of the late ’80s and early ’90s was too rigid to support data traffic and thus routing replaced it. The PSTN and TDM were too rigid as they doled out bandwidth in 56Kbs chunks and were unable to support internet and VoIP traffic. The national entertainment network is rigid too as it doesn’t support two-way communications and it also will be replaced slowly but surely.

So where is networking not flexible enough? It’s in virtualized data centers. Some analyst groups estimate that 30% of workloads are virtualized and increasing. Since virtualization or a VM is the new atomic layer of data centers, networking is falling short in public as well as private clouds. Ideally, all resources (compute, storage, and networking) would be pooled, with services dynamically drawing from the pools to meet demand. Virtualization techniques have succeeded in enabling processes to be moved between machines, but constraints in the data center network continue to create barriers that prevent agility, for example, VLANs, ACLs, broadcast domains, Load Balancers, Firewall/IPS Security settings and service-specific network engineering.

The well understood problem is that when a VM is moved from one physical machine to another the network, load balancers, firewalls/IPS, broadcast domains, etc., have to be reconfigured. There is no automation in place, meaning that the network is not flexible or agile enough to make the changes required. Now this problem has scale to it as it’s a growing requirement of both IT executives managing corporate IT assets and service/cloud providers.

There are market solutions available today and more are coming that address “network automation” which enable the network to reconfigure itself as a VM and/or workload is moved within a data center. Cisco’s Nexus 1000V, HP Network Automation software and its Virtual Connect approach, Force 10’s Open Automation, Blade Network Technologies VMReady Network Virtualization, Arista Network’s Virtualized Extensible Operating System or vEOS and others are addressing the problem of network agility or lack thereof in virtualized environments.

But the problem gets bigger and more complex when distance and cloud provider entities become engaged. None of the solutions above address moving a VM from one physical server to another over large distance, be it around town, across state lines, across the country or the globe. Some are using IF-MAP as a registry, sort of like facebook for computers that publish their resources and use this information to automate network configuration to support large distance VM moves.

The problem gets larger yet when workloads move from a private cloud to a public cloud. (Definition note: There is no single definition of a workload, so for my purpose here I assume a container including a VM and associated applications and data that can be moved as simply as drag and drop or some other string of instructions). In short, all the software that is needed to compile and run an application for a set of users is a workload. The network inflexibility problem grows even larger when moving workloads between public clouds.

Now is this a real problem? You bet it is. Consider the value also of portable or mobile workloads to Enterprise and service providers. Workload mobility means capacity on demand, business continuance, and disaster recovery, etc. In addition, as IT leaders explore public and private cloud alternatives, they will want to move workloads from their data center to a provider’s and move the workload back when and if required. For reasons of security and trust, IT business leaders will demand mobility. For example, if your cloud provider goes bankrupt, then you will want to move your workload out quickly. If your cloud provider’s performance drops again then you could move your workload out. If your cloud provider is the target of a terrorist attack or is turned into a large botnet then you can move your workload out.

In addition to security and piece of mind, mobile workloads will fundamentally change IT delivery, capital structure and most importantly business models and processes. Once IT can move workload anywhere in their data center, across their data centers or to a provider they have tiered with, the question becomes when and how fast does IT move workload? If IT can perform all the provisioning in software and enable workload moves to occur transparently and safely with address, identity, security preservation, enabled trust, control and interoperability across providers, then the question is when does IT need to move workload? This level of mobility is an industry-wide initiative as it offers significant and material business value. Business value is created as IT could move workload in a follow- the-sun model, following the lowest cost per kilowatt-hour model; workload could move to avoid a disaster, or for capacity on demand, or for lowest cost of workload execution, etc.

So how can data center networks become more flexible? A key element of the solution is agility or the ability to dynamically grow and shrink resources to meet demand and to draw those resources from the most optimal location. Today, the network stands as a barrier to agility and increases the fragmentation of resources, which leads to low server utilization and prevents portable or mobile workloads.

ShareThis

As cyber threats across the globe continue to increase in number and sophistication, security and networking personnel must not only work harder but also smarter to stay ahead of malicious attacks. Sophisticated scanning, penetrating, and obfuscating tools and techniques are more widely available now more than ever before. Worst of all, hackers are now highly motivated to penetrate networks, applications, and databases to steal information that can quickly be sold for profit using botnets and other resources
they control.

To learn how to defend IT assets and business reputation by download this paper from HP Networking.

Get the White Paper

ShareThis

The fundamental nature of data center computing is rapidly changing. The traditional model of separately provisioned and maintained server, storage, and network resources are constraining data center agility and pushing budget envelopes to the limit. IT organizations recognize that these static pools of isolated resources are being underutilized, a problem that can be exacerbated when dedicated infrastructure or computer systems are used to support different classes of data center workloads. One response has been for IT organizations to adopt virtualization and blade technologies, which enable a more flexible and highly utilized infrastructure. These new, more scalable technologies can be dynamically provisioned to meet continuously evolving business requirements. At the same time, these technologies apply new pressures to the multiple networks in the data center, further worsening spend issues. And it increases the burden on the IT teams that support them.

Learn how to avoid these data center problems with HP FlexFabric by downloading this white paper:

Get the White Paper

ShareThis

Traditional security techniques are unable to respond to threats that can arise from anywhere. To protect today’s borderless networks, IT managers must adapt by implementing faster, smarter security measures that monitor the constantly changing global landscape. This white paper, written for IT managers and executives, examines the security risks and needs of borderless networks, details a systematic plan of action, and describes how Cisco can help implement threat defenses that will serve you today and for years to come.

Find out how by downloading this white paper

Get the White Paper

ShareThis

Listen to the Podcast

ShareThis

For high-end data centers, HPC plus private and public cloud computing networks connecting thousands of servers, a new set of requirements have emerged. Low latency and high performance are the two driving requirements. Yes, there are more, especially when the fabric needs to enable converged storage, but let’s focus on latency and performance for now. Traditional three tier (server access, distribution and core) fabrics designed primarily for north-south traffic flows, that is client-server computing utilized spanning tree protocol (STP) and slower speed Ethernet (100Mbs to 1Gbs). Thanks to web 2.0, mash-ups and social networking sites east-to-west or server-server traffic flows have spiked requiring networks to support both north-south and east-west flows.

As most network engineers know, STP was designed to avoid loops that confused Ethernet as it was designed as a bus topology. STP shuts down redundant links between common switches to maintain the bus. Therefore, connecting access switches to distribution switches utilizing STP would require that network engineers over-subscribe the links between switches as only half of the bandwidth could be used. Oversubscription would also create blocking of packets between points too. To avoid this design, nearly every major switch manufacturer offered link aggregation that is the ability to shut off STP and aggregate links between switches. While this was and is a benefit, the down side has been that vendors only offered the ability to aggregate two links, which still drove oversubscription and blocking.

Recently, industry players such as Cisco and Arista Networks have offered the ability to scale up aggregation of links from 16 to 32, while at the same time delivering multipathing that allows packets to be forwarded across multiple links to arrive at its intended destination. Switch-processing capacity to support these massive inter-switch links have been increased too. These design changes, along with Ethernet’s innovation march, has ushered in the two-tier network design fabric option.

A two-tier fabric is designed with two kinds of switches; one that connects servers and the second that connect switches creating a non-blocking, low latency fabric. We use the terms ‘leaf’ switch to denote server connecting switches and ‘spine’ to denote switches that connect leaf switches. Together a leaf and spin architecture create the network fabric.

In late June 2010, Cisco announced its’ FabricPatch Switching System or FSS and its’ F-Series modules that support 32 ports of 10GbE of auto-sensing 1/10GbE and is essentially for server access and aggregation. FabricPath provides a new level of bandwidth scale to connect Nexus switches and delivers a new fabric design option with unique attributes for IT architects and designers. FabricPath is a NX-OS innovation, meaning that its’ capabilities are embedded within the NX-OS network OS for the data center. FabricPath essentially is multipath Ethernet; a scheme that provides high-throughput, reduced and more deterministic latency, and greater resiliency compared to traditional Ethernet.

FabricPath combines today’s layer 2 or Ethernet networking attributes and enhances it with layer 3 capabilities. In short, FabricPath brings some of the capabilities available in routing into a traditional switching context. For example, FabricPath offers the benefits of layer 2 switching such as low cost, easy configuration and workload flexibility. What this means is that when IT needs to move VMs and/or applications around the data center to different physical locations, it can do so in a simple and straightforward manner without requiring VLAN, IP address and other network reconfiguration. In essence, FabricPath delivers plug and play capability, which has been an early design attribute of Ethernet. Further, large broadcast domains and storms inherent in layer 2 networks that occurred during the mid 1990s have been mitigated with technologies such as VLAN pruning, Reverse Path Forwarding, Time-to-Live, etc.

The layer 3 capabilities added to FabricPath deliver scalable bandwidth allowing IT architects to build much larger layer 2 networks with very high cross-sectional bandwidth eliminating the need for oversubscription. In addition, FabricPath affords high availability as it eliminates STP, which only allows one path and blocks all others, and replaces it with multiple paths between endpoints within the data center. This offers increased redundancy as traffic has multiple paths in which to reach its final destination.

FabricPath employs routing techniques such as building a route table of different nodes in a network. It possesses a routing protocol, which calculates paths that packets can traverse through the network. What is being added to FabricPath is the ability for the control plane or the routing protocols to know the topology of the network and choose different routes for traffic to flow. Not only can FabricPath choose different routes, it can use multiple routes simultaneously so traffic can span across multiple routes at once. These layer 3 features enable FabricPath to use all links between switches to pass traffic as STP is no longer used and would shut down redundant links to eliminate loops. Therefore, this would yield incremental levels of resiliency and bandwidth capacity, which is paramount as compute and virtualization density continue to raise driving scale requirements up.

Designing A 160 Tbps Data Center Fabric

As an example to how multi link aggregation, the elimination of STP, high switching capacity and 10GbE connections create a highly scalable two-tier layer 2 Ethernet fabric, we use Cisco’s FSS and its’ F-Series module in the Nexus 7000. The following details the design of a 160 Tbps switching fabric with FabricPath and the F-Series module for high performance data centers using Cisco’s Nexus 7000 switches. This architecture can support over 8,000 servers connected at 10GbE or 4,000 servers dual homed at 10GbE with attributes of being non-blocking, low latency (5 microseconds), high bandwidth, reliability, plus simplicity of workload movement.

To build a 160 Tbps two-tier fabric, thirty-two Nexus 7018 switches populated with F-Series 10GbE modules would connect servers. These thirty switches are leaf switches. Each leaf chassis provides 256 10GbE ports to connect servers and another 256 10GbE ports to connect into spine switches. Therefore, each leaf is directly connected to each spine with sixteen FabricPath ports at 10GbE equaling a total of 256 10GbE ports for each leaf switch. There are sixteen spine switches each accepting 512 10GbE FabricPath ports. A single leaf chassis connects 256 10GbE ports into a spine equaling approximately 2.5Tbs. Multiplying each thirty-two leaf’s contribution into the fabric yields 80Tbs. As Ethernet is full-duplex, the total fabric switching capacity is 160
Tbps. Therefore, 160Tbps of switching fabric is available across all thirty-two leaf chassis. As 256 10GbE equals 2.5 Tbs, which also equals 16 FabricPath links to each one of sixteen spine switches, yields 2.5 Tbs, the fabric is non-blocking.

As for layer 2 and layer 3 forwarding, the job of the spine is to forward packets from leaf switches at layer 2, creating a single tier fabric. A key attribute of this architecture is that each 16-way FabricPath links are Equal Cost Multipathing or ECMP. What 16-way FabricPath ECMP provides are two benefits: 1) It delivers more paths for traffic to flow, which increases available bandwidth in the fabric and 2) as they’re distributed across all switches, diversity of routes is enabled to distribute packet forwarding. In essence what 16-way FabricPath ECMP provides is a very low latency, high bandwidth approach to supporting both north-to-south and east-to-west traffic flows simultaneously.

While the above is a Cisco deployment example Arista’s new 7500 series of Ethernet switches support 6 Billion packets per second at wire speed. The 7500s can be configured into a massive two-tier network fabric thanks to it support of 32 port MLAG (Multi-Chassis Link Aggregation) affording the connection of 18,000 to 30,000 servers.

Ethernet continues to evolve. The IEEE recently ratified the 40 and 100 GbE standard with vendors such as Force 10, Cisco, Arista, Extreme, BLADE, Brocade, Voltaire, HP et al announcing support and scheduling product delivery. While the above two-tier network example provides the perspective from the large switch provider, below is BLADE Network Technologies perspective, a company focused on server connectivity.

BLADE Network Technologies believes that as Ethernet delivers new levels of speed and intelligence, it will be the dominant two-tier network fabric for high-end next-generation data centers.
For many applications, low latency is a key requirement, and latency is an area where two-tier networks excel. Studies of stock trading exchanges have shown that tens of milliseconds of delay in data delivery can represent a ten percent drop in revenues, and delays of even five microseconds per trade can cost hundreds of thousands of dollars. Industry-specific requirements for uncompressed data and end-to-end deterministic latency within tens of microseconds make attaining such performance even more difficult. These factors have combined to make raw switching speed a top priority, and today’s best-of-breed 10 Gigabit Ethernet switches achieve can operate with under 700 nanoseconds of port-to-port latency while consuming a miniscule amount of power equivalent to that of standard light bulbs.

As next-generation networks get flatter – driven by latency and bandwidth requirements – emerging Layer 2 technologies such as the IETF’s Transparent Interconnection of Lots of Links or TRILL, enable this trend. The idea behind TRILL is to replace spanning tree as a mechanism to find loop free trees within Layer 2 broadcast domains. Using a routing protocol to build forwarding trees within a Layer 2 broadcast domain enables the flexibility and efficiency to route Layer 2 traffic, just like one would Layer 3 traffic, without the overhead associated with Layer 3 packet processing. TRILL will offer important features, such as support for both broadcast and multicast, load splitting along multiples paths, support for multiple points of attachment, and no tangible delay in service after attachment.

In the data center, bottlenecks are moving from the CPU and memory access to the I/O of the servers. Today’s multi-core servers are now able to sustain a great amount of traffic, requiring fast, flat networks, especially now that virtualization is widely deployed. Analysts have predicted that the 10G market will double year-to-year in 2010 and 2011. More servers using 10G increases the requirement for 40G and 100G in upstream networks. With 10G widely available and 40G coming online, Ethernet networks can enable data and storage traffic to use a single wire, using FCoE or iSCSI for example, and provide the raw speed that makes Ethernet with its economies of scale, to supplant InfiniBand for HPC requirements.

The reason Ethernet will be the network fabric for high-end data center networks is that the vendor community continues to innovate and build upon this protocol. Ethernet innovations are many and are beyond bandwidth increases from 10Mbs, 100Mbs, 1Gbs, 10Gbs, 40Gbs and 100Gbs, which are obvious. Link aggregation, multi-pathing and so much more propel Ethernet’s relevance and suitability to new challenging networking requirements.

ShareThis

Watch the video now here

Visit the Link

ShareThis

Spanning-Tree Protocol (STP) can be easily compromised by eavesdropping in a switched corporate environment, but this vulnerability can be mitigated using L2 security features that are available on the Cisco® Catalyst® 6500. STP Man in The Middle (MiTM) attack compromises the STP “Root Bridge” election process and allows a hacker to use their PC to masquerade as a “Root Bridge,” thus controlling the flow of L2 traffic. To understand the attack, the reader must have a basic understanding of the “Root Bridge” Election process and the initial STP operations that build the loop free topology. This paper provides an overview of the STP Root Bridge Election Process, STP MiTM Attack Guide and Mitigation Techniques for STP attacks.

Find out how by downloading this white paper

Get the White Paper

ShareThis

There is no doubt that the unified communications and collaboration industry needs interoperable solutions. Video traffic, in particular, is growing exponentially, which will not abate anytime soon. Driving growth is the new mobile video market with devices being equipped with real time video applications from companies such as Apple with its’ iPhone 4.0 FaceTime feature and Cisco’s Cius tablet. There is a real-time mobile video chat for Android too via the Movicha client application. In addition, every major UC supplier will launch a tablet based, end user device this year with tight links into its UC and video collaboration infrastructure. In short, the next generation office phone is a tablet. The combination of consumer and business mobile video device options will drive demand for interoperability, not only between mobile end points, but into corporate video conferencing systems too.

There needs to be a base line of interoperability standards for presence and call management also. Yes SIP or session initiation protocol does provide a base line, but many have built proprietary extensions minimizing interoperability options.

Now is a great time for an industry wide consortium of suppliers, service providers, IT executives and analysts to contribute to a set of interoperability standards with associated certification testing. Before UCIF was established Microsoft drove the initiative with limited to no input or invitation from its competitors. This approach has alienated nearly every major UC supplier from participating in UCIF, and therefore, don’t expect to see Cisco, Avaya, ShoreTel, Mitel, NEC et al to contribute. From this point of view, Microsoft killed UCIF before it even started.

But UCIF can make a contribution especially in the area of real time video collaboration between mobile, desktop and video conferencing system end points. For example, Microsoft could open up its’ Real Time Video (RTV) and Real Time Audio (RTA) codec protocols so that mixed vendor video endpoints can communicate with Office Communicator endpoints natively. With LifeSize, Polycom, HP and Microsoft being the UCIF founding members, their contribution to video collaboration interoperability could have a large impact on the real time video conferencing market.

For example, I use a LifeSize Express 220 video conferencing system, and as a standalone device that connects to other video conferencing systems via IP, H.323 or SIP, it’s magnificent. It would be great to connect with clients that have video enabled their desktop and mobile endpoints too. The larger the universe of potential video endpoints that one can connect to, the greater the value a real time video system provides. This would be a great charter for UCIF, which is to contribute open standards and certification testing that enable mobile, desktop and corporate video conferencing systems to interoperable.

However, for UCIF to deliver on its charter, it would have to dissolve and restart with Cisco, Avaya, Mitel, ShoreTel, and a larger role for Siemens, plus service providers, analysts and IT executives all being stake holders. You cannot have a closed group defining open standards. It just does not work that way.

ShareThis