IP Convergence: Beyond VoIP, Beyond Cost Savings

I had the opportunity to present the latest message from Global Crossing in support of Unified Communications.  On March 27th, I attended a panel discussion at Sun Microsystem's Boston campus for masnetcomms.org and on March 28th I presented at a Global Crossing VoIP seminar in Cleveland.

My massnetcomms presentation was focused on the technology enablers (Simple Object Access Protocol (SOAP), XML, Service Oriented Architecture, Price performance of general purpose computers , Software As a Service model, Network Convergence (IP and access),  Protocol Convergence (SIP)) that have created the opportunity for Unified Communication adoption.  Unified communications is not a new concept, it’s about 10 years old and really never took off.  The early UC models were all hardware centric with specialized devices and lacked seamless integration into your desktop.  However today,  companies like Microsoft have taken a software only architecture that leverages their installed base of email (exchange) and identity (Active Directory) into realizing a seamless experience on my desktop.

In Cleveland,  I shifted the discussion to a more network centric message and highlighted our internal IT success in deploying Microsoft OCS . Global Crossing’s internal IT team began the road to Unified Communications in 2003 when we deployed Cisco VoIP handsets . 

The 2003 VoIP deployment was an important milestone in that both the network (LAN, WAN) and operations (Voice vs. Network team)  had to come together and provide a reliable and consistent transport for Voice, Video and Data. This is an excellent example of IP convergence providing a solid foundation for our subsequent deployment of Unified Communications. 

In 2005 Global Crossing deployed Live Communications System (LCS)  (LCS is the predecessor to Office Communications System (OCS) ) and in 2006 our first deployment in support of Microsoft OCS beta.  Global Crossing was one of 72 companies supporting the beta and tap phases of OCS  and in October 2007 supported Microsoft with their OCS  launch in San Francisco.

What we are experiencing is that not only can OCS provide unparalleled  integration into our desktop environments, but more importantly business transformation as it is now embedded into our workflow, sales portals and company directory.  We are able to work more efficiently , with better communications which will add to a better customer experience.

But the deployment of Unified Communications didn’t start in 2005 when we deployed LCS, it actually started in 2003 when we began deployment of a converged network.

At both presentations the message reasonated with other industry leaders and customers. Clearly IP and network convergence provides the foundation for a successful deployment of Unified Communications.

While visiting with several individuals a few weeks ago at the Ziff Davis Unified Communications Summit in Seattle, WA I noticed that some people hadn't yet realized the power of one aspect to the overall value of unified communications which relates to presence awareness. That is leveraging presence not just in instant messaging but in other communication vehicles can play an important role in transforming your business impact as an IT organization. As a result I thought I would dedicate this post to help create ideas around things that can be done to assist in helping IT in leading the way.

Here at Global Crossing in an attempt to leverage this core components of Unified Communications in an ongoing effort to incorporate the advantages of collaborative, converged services within our enterprise we've transformed internal applications from static non presence aware to anticipatory engaged communication tools that are supporting contextual collaboration with presence-awareness throughout the enterprise. In this instance presence-awareness (whether someone is available in simple terms and how to contact) is utilizing capabilities including chat, computer-based telephony, conferencing, IP video, and e-mail across tools that leveraged across the enterprise drive in principle more efficacy from consumption and corresponding execution. In fact it is my opinion that since presence has been embedded into our application infrastructure to enhance our collaborative capabilities it is natural to see transformational improvements occur around our "quality of experience" associated to the overall user experience. This is so because enabling enhanced customer experience truly enables the IT organization to drive one more component to our IT organizations transformational success in enabling the business to not only "react" but be proactive by achieving extensibility required within the distribution transparency model required for execution. Said another way the fact that presence awareness has been integrated into our application infrastructure means this action will further enhance our agility to enhance operational efficiency by allowing application "pivots" to be present thus accelerating communication by eliminating in some instances serial cognitive task execution.

As the industry landscape continues to evolve there are a few constants that will remain the same: (1) increasing business demands require more innovative, transformational capabilities between employees, partners and customers and (2) continually driving operational velocity reductions around the cost basis of delivering information technology services is imperative. It is commonly believed by many vendors such as Avaya, Cisco, Intel, Nortel and Siemens as well as software developers such as IBM and Microsoft that presence technology will continue to become an increasingly important tool at driving traditional costs out by attacking the serial nature of traditional work execution thus increasing operational efficiency.

So why is presence so important to Unified Communication services? Presence is important because it can become the intelligent communication application for converged IP communication services such as those demonstrated by our IT organization at Global Crossing. Determining where a user is and how best to reach them in our case by leveraging presence enabled applications that have been integrated into our infrastructure with the "glue" to increase the overall value of our converged IP services brought to the table and help realize substantial business transformation value.Said another way presence-aware applications offered on a converged IP communication service help evolve traditional serial actions of quickly determining and thus engaging with employees regardless of location, modality or scheduling which allows our globally dispersed users to communicate and collaborate in real time providing productivity in a truly global and mobile workforce environment. Combined converged IP communication services with presence technology provide for accelerated collaboration between our employees, partners and customers by knocking down the walls of traditional serial communications and by accelerating communication through anticipatory engagement.

Presence is the value.

In a comment on this post from one of our readers, Christopher Wacker writes:

To me, it sounds like you A/V issues lie with your networking.  I work for a MPLS consulting firm (if you don't know what MPLS is, you can take a look at http://mpls-experts.com/default.asp?page=pages/whatismpls.asp&v=nontech for a brief overview of what MPLS is) and have noticed this problem quiet often with companies.  Are you currently using ATM/Frame Relay?

I am somewhat familiar with MPLS.  :-)

I was an IP Engineer at Frontier Globalcenter when we were doing our rollout of MPLS back in Q1 1999, which coincidentally was the first deployment of MPLS in any production IP network anywhere.  We deployed the mesh nationally in Q2 of 1999, and according to our primary core vendor at the time (Cisco), we were the first carrier with a nationwide deployment of MPLS. With the acquisition of Frontier by Global Crossing, we began building new POPs internationally in Europe and Latin America over the first half of 2000, and our US domestic MPLS core became an international one..

It was a tough time for us to deploy MPLS.  The standard was so new it wasn't even a standard yet, it was still in draft.  There were lots of bugs in our vendors' routing code.  Deploying Juniper created additional complexities because each vendor interpreted the RFC's and Internet Drafts (pre-RFC's) differently, which occasionally led to some very interesting network behavior.

But I digress.

Towards your question around the use of ATM/FR, I am not directly connected to our corporate network with ATM/FR or MPLS, which is the root of my problem and a common plague of the telecommuter.  I use a local ISP who buys transit from someone other than Global Crossing, and the performance is often less than desirable. 

For the sake of argument, let's say that I was connected directly to the corporate MPLS network, would my QoS problems be solved?  Would I be able to set different ToS bits on the video packets coming from communicator compared with the voice?  As near as I can tell, there are no such settings in MS Communicator 07, and if that is true, then all packets originating from my computer will look like any other data packets and will not get any special treatment on the network. 

QoS on MPLS works great, but if you can't differentiate packets in some way (IP address range, port range, or ToS bits) you won't be able to take advantage of it.  Usually, differentiating packets within the same application (say OCS) is impossible to anywhere other than the application itself.  I say usually because it is possible that if the application uses different ports on seperate rtp streams, and you can tell which one will always be video and which will always be voice, you can probably work something out on the CPE router to classify the packet, but it would certainly be easier to just set the parameters in the application.


Perhaps one of our readers knows if it is possible to set the ToS packets within OCS?

Here's the second part of our Virtualization series  and a continuation of Virtualization -  Part 1 – The Abstraction of the Internet.

A computer consists of several key elements that along with software (and firmware) provide useful applications like the browser you are using to read this blog from our web servers.

Here are some of the items that are noteworthy:

Central Processing Unit (CPU) – aka Pentium for you wintel folks, is the heart of the computer and executes instructions (software or firmware) that are programmed by a software engineer.

Input/Output Devices – Provides a method to enter , display or share information from the computer, for example:  Display, keyboard, mouse.

Random Access Memory (RAM) – Is memory that is accessed by the CPU which losses its contents when you remove power.  RAM (Typically) is the fastest memory that a CPU and “read” or “write”.

Disk Drive – Is memory that is also accessed by the CPU which doesn’t lose its contents when you remove power.  Disks are slower than RAM.

Flash Memory – Is like RAM but has the characteristics of a disk drive.

Data Bus – Depending on the CPU (8 bit, 16 bit, 32 bit or 64 bits wide) is where the CPU can read or write data from or to the various memory devices,  Input/Output devices.  Each bit is a “1” or “0”.

Address Bus – Also dependent on the CPU , this is where the CPU (using bits) selects the location in memory to read or write data.

Firmware – aka BIOS for wintel folks, is software that is used to “boot” (restart from a known state)  the computer that resides in Flash memory or a Programmable Read Only  Memory (PROM).

Software – eg Office.

Operating System – eg Windows, is a layer of software that abstracts the hardware and controls the overall operation of the computer.

Networks – Are communication systems that allow computers to share information.

Programming Languages – A CPU can only understand binary (“1” or “0” s) for the  instructions it executes.  There are various instructions to read , write, add, multiply, subtract , divide and move data. However, Humans need to abstract the instructions into words to make it easier.  These languages define the way words are used forming a grammer (just like English or Spanish) .  The first form of languages are assembler languages which are specific to a CPU and not portable, the subsequent languages like C, C++, FORTRAN, Pascal provided more functionality with Database languages like 3GL, 4GL etc..

A computer can be a main frame, a desktop or your laptop which were confined to a area (room, your desk or your lap).

Advances in networking have provided efficient methods of distributing the CPU from Disks, Input/Output devices. 

Storage Area Networks are clusters of disk drives that are no longer directly connected to the computer using the various buss’s described above. This is a key level of abstraction which has allowed distributed computing to evolve into GRID computing where the software is one place, the CPUs in another and memory in yet another.  Distributed computing provides more efficient use of computing at unparalleled  level of disaster recovery.

Why is this important? 

Computing has and will continue to be the mother of invention for advances not only in the hardware or software but also in the networks that connect everything together like the Internet or also an Enterprise VPN.

More later :

Virtualization – Part 3  - The Abstraction of Applications
Concepts of a Application Programmers Interface (API),  examples and pitfalls for APIs and the abstraction of  Web Services.

Wow, things really do happen fast and a great example of “internet time”.

Here’s the result of my prediction on March 19th.

Watch out Voice based directory services have just been disrupted and expect Google to be leader in this space.

Seems that the financial community has started to understand how companies offering VoIP services need to be reevaluated. 

Today Credit Suisse reiterating their position on Sonus Networks, resulting in an almost 6% increase in stock price - Sonus' 52 week high.

Look at Vonage and they have over 2.2 million subscribers, an almost 50% increase from the 1.4 million subscribers in 2005.

For Global Crossing,  the future looks brighter everyday.  And it's just not me saying it,  it's the analysts and media as well.

INTERNET TELEPHONY magazine  has recognized Global Crossing VoIP On-Net Plus Service™ with its 2006 Product of the Year Award.

VoIP On-Net Plus is a service that recognizes that transformation into the VoIP world is not a flip of a switch, it's a transition over time.  VoIP On-Net Plus allows an Enterprise the ability to share a private dial plan across their TDM and VoIP sites.

We use it internally and it's great to not have to remember 10 plus digits to contact any resource across the globe.

Check it out!

Although I support and wish them luck, a call to action to remove VoIP barriers internationally is a daunting task.

In Jeff Pulver's blog dated December 15th, 2006,  I quote my comment dated December 18th, 2006:
"Jeff [Pulver], I wish you and the VON Coalition good luck.

However it may be an up hill battle that is based on each countries political and bureaucratic process. Let’s not forget that the incumbents grew out of the PT&Ts (Post Telephone & Telegraph) and they would act in the best interest of a country and not the market.

History has many examples of how this played out, remember the proprietary signaling protocols across international boundaries, remember that some PT&Ts were successful in blocking entire NPAs in an effort to stop international toll bypass.

Countries like India have embraced VoIP as a technology enabler to grow their share of the outsource call center market, but stop short of allowing VoIP to originating or terminating within their PSTN.

Other countries like China have adopted a policy of licensing and setting the cost at (un)reasonable level – estimates as high as $2M US.

You may want to take the India policy as an example of allowing VoIP to enable a market. And replay this to countries like Malaysia which are up and coming outsourcing countries – as a start."

Take a look at a Global view   VoIP regulations as developed by the Global IP Alliance.

Typically, countries have taken an open market approach to spur innovation, a middle ground approach to control innovation and a  “not in my back yard”  approach to stifle innovation.

A PT&T approach of stifling innovation is a near sighted perspective to protect tax revenue and the incumbent’s control – far a market perspective the market will move those calls via VoIP to countries that are either in the open market or middle ground approach.

For example,  US and Europe are open market countries,  India is a middle ground country,  and China is “not in my back yard”  country.

So how can you move China into the middle ground?

I think we should use India’s logic, in  providing cost effective communications (VoIP inbound/outbound)  to support outsourcing while  leveraging low cost labor.

I have been a fan of Geoffrey Moore for over 10 years and have found his book entitled “Crossing the Chasm” both inspiring and true to life.

Crossing the Chasm defines a technology adoption cycle across atypical buying patterns across a generic industry.

The early market is segmented into 2 groups – 1. Technology Enthusiasts (sometimes referred to Early Adopters)  and 2. Visionaries.

While the mass market is segmented into 2 groups -   1. Pragmatists , and 2. Conservatives 

With the laggards in technology acceptance are found  in the last segment -  Skeptics.

The  key to reading this graph is that a product/service revenue is the area under the curve. Clearly the mass market represents where the money is to be made , while the early market and laggards represent a small percentage of potential revenue as it relates to the mass market.

Product and Service adoption generally follows  a “product adoption process” defined by “The sequence of stages that individuals and firms go through in the process of accepting new products. The stages vary greatly in usage, but tend to include (1) becoming aware of the new product, (2) seeking information about it, (3) developing favorable attitudes toward it, (4) trying it out in some direct or indirect way, (5) finding satisfaction in the trial, and (6) adopting the product into a standing usage or repurchase pattern.”

One of my roles at Global Crossing is supporting our product teams on industry analyst meetings in both a technical and customer facing aspect on Advanced Solutions.  General industry estimates suggest  a small percentage of deployed IP-PBXs in the US are managed.

Do these estimates suggest a historical  trend that will play out in future years?

Or do these estimates suggest production adoption cycle where the 400,000 IP-PBX deployments are  representative of the early market and that the mass market will require management of these IP-PBXs?

I tend to feel the later is in play.  Why?

The early market , typically , in technology adoption tends to be more technology inclined.  They accept new technology with little or no documentation ,  work thru pioneering adoption issues and are very forgiving.  While the mass market is not.

The early market will take technology risks,  while the mass market will not. Global Crossing adopted VoIP within our internal operations starting  in 2002, clearly a early market adopter.  We had (and have) the technologists,  the willingness to adopt and the patience.  Today over 65% of the user base and over 90% sites  use  VoIP daily.

Another role of mine is supporting our sales channels in solving customer requirements that are beyond our generally available products that are considered Advanced Solutions.  Within the last 3 months I have seen several large Mutli-National Companies (MNCs) move from a ‘let’s build a new VoIP platform’ to “let’s buy and use an existing , operationally proven VoIP platform’.

Connect the dots,  place your bets that managed VoIP will overtake unmanaged VoIP as it becomes adopted by the mass market.

I read an interesting article tonite entitled “Universal VoIP Peering Faces a Rough Road “

VoIP peering is not a flip of the switch. Look back at history as to how the PSTN was built – over time and by market forces.

Bell’s initial success was in local operations, and over time these local operation islands were connected as part of “ATT long lines”. In the US , Bell didn’t have a lock on all local operating markets, there were numerous independents: GTE, United, SNET, Rochester Telephone, etc.... The success of the early PSTN required an ability to terminate calls outside of a LEC footprint, and even required diplomatic functions for international termination.

The move behind VoIP peering is a uni-lateral move by all providers to be free of PSTN regulations, tariffs and government.  The benefit for providers is lower cost and competitive freedoms;   the benefit to consumers is greater options.

Let’s look at a more recent example of technology based islands, ISDN. ISDN early promises of adoption were plagued by a lack of national (and international) standards,  both ATT (now Lucent) and Northern Telecom (now Nortel Networks)  had competing  technology implementations, both fought within the standard bodies to have a lock on the accepted standard that bonded LEC ISDN islands. And in the US National ISDN2 became the standard bodies that provided a pathway to ISDN connectivity, add ETSI and the ITU international interoperability became a reality.

It took a fragmented ISDN standard to become a ubiquitous service almost 10 years.

VoIP, SIP, IP are interoperable today and had become a pathway for VoIP peering.

The road to VoIP peering is not a rough road but a known road.  The early pioneers who provide that vehicle will be part of the new VoIP based “long lines”.

I attended a meeting last week with a customer in the Media & Entertainment space, and one of the topics of discussion was that the standard billing method that most ISP's use doesn't work well for their type of business.

The standard billing method that I am referring to is P95, or 95th percentile billing. What we do is measure the input and output traffic on each circuit connected to our routers. Our equipment collects the interface counters every 5 minutes (approximately) and divides the result by the exact number of seconds since the last collection to get the rate. For example, over a 24 hour period you will have about 288 samples for each direction (in/out). We take out the biggest 14 of those samples and then use the remaining largest sample as the billing rate.

Most of the time, this works great. On your typical large ISP traffic trend you'll cut off the very top of the peak providing a good billing rate to traffic volume fit, like this (the red line indicates the P95, the rate at which the customer is billed):

On a content providers circuit this works pretty well too. Even when they have an "event" where they double their traffic due as the result of a new movie trailer release or one of their other providers going down, they don't pay for the traffic unless it's a regular event.

In the media business, or at least certain segments of that space, it is common to see much more erratic traffic patterns, such as a line rate usage for a couple hours out of the day. Doing some reverse calculation, the 14-15 samples in a day that get discarded comes to 75 minutes, and if you transfer a 200 Gig file in the morning on a DS3, assuming 40Mbps throughput, that transfer will take 83 minutes to complete. After throwing away the top 15 samples showing 40Mbps, the 16th sample (which gets used for calculating the monthly bill) is also 40Mbps, so you got charged for 40Mbps of bandwidth even though you only used it for barefly more than an hour each day. The graph below does not perfectly illustrate the situation, but it is a weekly traffic graph from a real media customer of ours in Los Angeles.

There are two potential solutions for this problem.

Option 1) and probably the easiest option is to develop a pricing model that is by the Gigabyte instead of P95 of the rate. Since we know exactly how many Gigabytes are transfered, all we need to do is calculate a price/gig that will yield a more competive rate and remove some of the calculations from the billing and rating algorythm.

Option 2) and much more complicated is to build an event system where the amount of bandwidth can be automatically re-provisioned for the customer either as the result of an XML data input into our customer portal or as the result of some other automatic feedback mechanism such as link threshhold monitoring with an event trigger. Tie that in with automated network provisioning tools, and a billing system that can support a large number of pro-rated bandwidth purchases over a given month.

Why do the more complicated one when you've got an easier solution at your disposal? To solve the specific problem, option 1 is most certainly the way to go, especially in the short term. Option 2 has the advantage of setting the stage for a massive increase in functionality, particularly when it comes to having applications automatically manage how much of a particulary QoS/CoS they need in order to operate properly.

If you've got ideas on how Option 2 might pave the way for you to do some interesting things for your business, drop an idea in our suggestion box by leaving a comment.