Federation Gateways: A Tipping Point for Unified Communications?

In several recent papers[1], I have written about the possibilities of inter-domain federation within UC systems and considered how this feature might replace the PSTN as the main business communications network. Federation is the feature that provides full multi-modal communications between enterprises and also between enterprises and consumers, over an IP network (e.g. the Internet).

Unfortunately, the only current federation implementations are between users of Microsoft Office Communications Server 2007/R2/Lync as well as between the users of Cisco Unified Communications System Release 8.0 (for a more detailed description, see 'Federation, Monarchy or Anarchy?').

Why do I think that federation is such a good thing? Isn't your father's plain old telephony good enough?

UC ROI Realization Challenges

If UC isn't significantly improving your productivity, it is probably because you don't have access to federation. Anyone who has experienced UC will know what a great enabler it can be. However, if the only people with whom you can communicate are your colleagues, then the utility is necessarily limited. Unless you are a telecommuter, or work in a small company or branch office, the option to meet directly with colleagues is usually available. The power of UC is in facilitating long-distance interactions that are as rich as those that you may have with the person who works just down the hall. I used federation frequently during my 6+ years in the Microsoft Unified Communications Group to communicate with business partners, and it not only works flawlessly, it is better and cheaper than traditional phone calls or ISDN-based video conferencing. Having the opportunity to be able to communicate with business associates in other companies with the same rich, presence-driven, collaboration features that are used inside the company is invaluable.

So, if federation is the "killer app," then why don't more UC vendors ship it?

Internet-based Federation Challenges

From a technical and risk management perspective, setting up an inter-domain UC session (i.e. across the Internet) is not the same as setting up an intra-domain session (i.e. within the corporate firewall and within the same UC system). At its most fundamental level, setting up an intra-domain session is what the UC system does - the UC user reasonably assumes that everything from an IM chat to a data collaboration session will be routed and enabled because all users are on the same system. Challenges for establishing inter-domain sessions are exponentially greater, but those challenges are not insurmountable.

Interoperability

This is the big one. With the possible exception of voice[2], the standards do not yet exist for inter-domain UC federation. As we all know, every vendor has implemented their UC system slightly differently, even when using the same technology. Therefore, the only way to guarantee that functionality will work between UC systems is for them to be from the same vendor and, often, be the same software version. It took nearly 6 years for the SIP Forum (a consortium of UC vendors) to agree on a voice federation standard (see footnote 2 below) - so my confidence that we will have standards for, say, web collaboration anytime soon remains low. However, I hold out hope for a different interoperability mechanism below.

Security

Clearly, the Internet is not a private network and the threats of non-lawful interception, identity spoofing and toll fraud are very real; not to mention outright cyber-attacks on a corporate network. The technology and standards to prevent UC sessions traversing the Internet from being hijacked for these purposes are well established, but not widely utilized. Many SIP Trunk services offered by telephony service providers require SIP messages and voice media to be sent unencrypted; which is just a bad security practice. The SIPconnect 1.1. Technical Recommendation referred to above strongly advises the use of TLS and SRTP to encrypt signaling and media.

In order to establish inter-domain encrypted sessions, the domains must first authenticate each other to ensure that a session is not being established with an attacker that is spoofing the identity of a legitimate domain. Once again, the technology for doing this is well established, but not widely deployed in UC. Digital certificates[3] from a trusted certificate authority are used every day in applications like online banking, and this is what is used in the TLS Server Authentication Model[4].

Of course, encryption and authentication are necessary, but insufficient. There are other Internet-borne attacks that a UC federation system will encounter, such as Denial of Service. A robust network edge security strategy must ensure that the Internet-facing element is capable of withstanding determined assaults by cyber-attackers without failing or becoming compromised. For a cyber-attacker, causing such a failure is an end-goal in itself, and taking control of the element, either to steal credentials or to directly access the internal network, is the ultimate goal. Internet-facing elements must be "locked down" to reduce the attack surface and be capable of ignoring non-authenticated traffic. These are standard functions of the server element often referred to as a Session Border Controller (SBC).

Privacy vs. Discovery

One of the key concerns about Internet usage is the loss of privacy and the ability to go about one's business uninterrupted. We are already subject to telemarketing, unauthorized data capture (e.g. recorded searches and the placement of cookies on our computers), SPAM and various Internet advertising gambits (e.g. pop-ups), so the creation of new opportunities for loss of privacy is unwelcome. Preventing additional privacy loss via federation is partly the function of the security technology discussed above. However, if we ensure total privacy, then not even those with whom we might wish to communicate will be able to contact us; thereby ensuring that UC federation would be completely useless. There must be a balance between the need for privacy and the need for "discovery," i.e. being able to contact the people with whom we have a legitimate need to communicate.

This is actually not such a big problem. Firms do not publicize their telephone or email directories because, as discussed above, they don't want their employees to be subject to unwanted communications; nevertheless, billions of phone calls and emails are exchanged daily. Business communications are facilitated via prior relationships and various social consent and referral protocols (e.g. the exchange of business cards).

Inter-domain discovery could be facilitated by implementing social protocols in technology. Business oriented social networking tools such as LinkedIn have extended human networking practices and thereby automated the process of discovery and referral. One of the simplest, most intuitive and most practical mechanisms is implemented in the Cisco Intercompany Media Engine, which allows a federated session if the two parties had previously participated in a traditional telephone call. Although this is not perfect for obvious reasons (e.g. we sometimes pick up on telemarketers) there is an expiry mechanism that withdraws consent for federation after a certain period.

There are advocates for a global corporate directory along the lines of the Domain Name System[5]: the proponents of ENUM[6] believe that the lack of such a directory is a direct impediment to the expansion of IP communications. However, UC systems inherently contain an ENUM-like directory in order for them to provide discovery within the domain. Therefore directories or parts of directories (e.g. for sales and support groups) could be federated to other firms according to policy settings without making them publicly accessible.

NAT and Firewall Traversal

The corporate networks are typically protected from unauthorized intrusion by "Network Address Translators" (NATs) and "firewalls." These devices are deployed in the network DMZ[7] to hide the internal network topology and only to allow validated traffic to pass to and from the core enterprise network. However, firewalls are primarily designed to cope with simple message-based traffic such as email (SMTP) and web page requests (HTTP), both of which are easy to inspect and validate. Therefore, most firewalls will block UC traffic because they are unable to cope with the complexity of UC signaling and the load of wideband IP codecs. Managing the traversal of UC signaling and media streams across the corporate network boundary is a key function of the SBC.

Several UC vendors (e.g. Microsoft, Cisco, Siemens) ship an SBC with their solution; others rely on 3^rd party devices[8]. Debating the merits of the various strategies for media firewall traversal is outside the scope of this paper. Suffice to say that "near-end" NAT/firewall traversal, (i.e. traversing your own DMZ), is a lot easier than "far-end" traversal, (i.e. traversing a NAT/Firewall that you don't own, such as those in your ISP network). Standards and technologies for this exist[9] but are not widely deployed in UC systems.

Audio/Video Quality over an Unmanaged Network

Part of the success of the Internet has come about because it is unmanaged and unregulated. However, this also means that there are no service level agreements: it is a "best efforts" network. This is not a problem for asynchronous communications such as email, because the email will normally reach its destination eventually without impacting the message quality. However, for synchronous communications such as voice, video, etc. this is a significant challenge; one which is made all the more challenging by the high bandwidth needs of these communications modalities.

As anyone with experience with long-distance telephone calls will know, the user experience can rapidly degenerate from ideal to unusable because of latency (aka "jitter"), i.e. the delay between one party speaking and the other party hearing the speech. One way latency of less than 150ms is ideal, but with latency between 300ms to 500ms conversation becomes difficult. With a latency of over 500 milliseconds, conducting a conversation becomes nearly impossible. Latency can be caused by several factors:

• The speed of light - the natural physical limit of electrons or photons (in the case of an optical network) traversing the distance between the parties;
  
  
• Processing - various types of hardware or software between the parties performing operations on the data packets, e.g. encryption/decryption, compression/decompression; encoding/decoding and transcoding (the conversion from one media codec to another);
  
  
• Network congestion - at bottlenecks in the network, the router software will place data packets into a queue (or buffer) while the backlog is being cleared.
  • Note that latency becomes even worse with every additional network junction that the data packet has to traverse, since route processing and possibly buffering will be applied each time.

If latency isn't enough of a challenge, then the loss of entire packets is even more challenging. Many of the voice and video codecs used in IP networks today rely on bandwidth reservation[10] (aka QoS) to overcome this challenge; however, this only works on managed networks and is unavailable for Internet federation. There are codecs that have been designed for use on the Internet and produce excellent results (i.e. far better voice quality than the PSTN) with as much as 10% packet loss. However, these technologies are subject to patent and royalties by the firms who made the R&D investments and therefore are normally only available for communications between the endpoints of that vendor. A full explanation of this technology is outside the scope of this paper, but it is interesting to note that much of the 'magic' is done, counter-intuitively, by:

• Increasing bandwidth by adding redundancy, i.e. sending the same data more than once in the hope that at least one copy will get through;
  
  
• Adding latency in the form of a 'buffer' which gives the decoder (i.e. the listening end) time to sort out delayed packets and to use redundancy to replace lost packets.

Federation Options

As described above, both Cisco and Microsoft have implemented different mechanisms to enable inter-domain federation in their UC systems, each of which addresses most or all of the challenges outlined above. However, if you are not a customer of either of those vendors, or if you need to federate with a business associate who is a customer of a different UC vendor, whether or not that vendor supports federation, you are out of luck. So what are the options (other than waiting and hoping)?

Federation Gateways

A federation gateway would be a 3^rd party element resident in the enterprise DMZ that implements the technologies described above in order to facilitate inter-domain federation. Most of the technologies described so far are already features of an SBC. Most SBCs also include "intermediation" capabilities; this is to say that non-interoperable SIP messages and codecs can be tweaked or transcoded by the SBC by implementing configurable policies and profiles. These profiles could be vendor or software version specific, thereby automatically mapping one vendor's UC implementation to another. Such a device would enable federation from (just about) any-to-any UC system, particularly for the "vanilla" modalities[11] (e.g. IM&P [instant messaging and presence], voice and video).

I am not currently aware of any shipping federation gateways from the SBC vendors, but I know from discussions with clients and industry contacts that this concept is being actively worked upon by several vendors. There is also a number of intra-domain gateways (e.g. Sametime/OCS gateways) that are normally IM&P oriented, but don't work for inter-domain, for "any-to-any" interoperability or multi-modally.

Clearinghouses

A clearinghouse is a federation gateway "in the cloud" or, if you prefer, "Federation as a Service." One of the benefits of a clearinghouse over a federation gateway is the need to maintain only one federation connection (i.e. a "hub and spoke" topology) rather than to many business partners (i.e. a "full mesh" topology). I do know, but am probably not allowed to reveal, the number of federation connections maintained by Microsoft IT. Suffice to say that it is a much larger number than you might believe and federation can potentially become a headache for network administrators (albeit that it is clearly providing value for the users).

I have long held the belief that Clearinghouses would be "the next big thing" in UC. I guess that UC in the cloud (aka CaaS or UCaaS) would have to take off first in order to for demand to build. However, there are some early implementations, such as that of NextPlane. NextPlane currently provides IM&P federation for IBM Sametime 7 & 8, Google Talk, Microsoft LCS/OCS, Cisco CUPS and Jabber; but suspect that multi-media federation is on the roadmap. They also ship an on-premise intra-domain federation gateway that could easily become a gateway to the cloud service.

Summary

In terms of reducing business travel and increasing communications immediacy and richness, the value of a UC system is greatly enhanced by the use of inter-domain federation to communicate with business associates who are outside the company. Certainly, UC has limited utility for communicating with someone with whom you could meet directly. The smaller the company, the more likely that UC will only be used for inter-domain communications. UCaaS will address the SME market segment, but there are already many UCaaS vendors who don't currently interoperate; so the missing piece of the puzzle for ubiquitous UC deployment is inter-domain federation.

Having only just "crossed the chasm," UC has yet to reach the level of deployment where we might reasonably expect any given business associate to already be a UC user. Once that happens, inter-domain federation will rapidly turn from a nice-to-have to a must-have feature.

Of course, there is a chicken-and-egg conundrum here: will ubiquitous UC drive inter-domain federation, or vice versa? Either way, given the complexity of inter-domain federation, it is clear that once the tipping point is reached, it will be too late for vendors to implement this feature and remain competitive. At the time of writing, Cisco and Microsoft, in line with their position in the Gartner UC Magic Quadrant, are the leaders in this space. However, the key to this market is 'any-to-any' federation, so the SBC and Clearinghouse vendors are well positioned to take advantage of this opportunity.

It will be fun to watch.

[1] "Federation, Monarchy or Anarchy?" describes a scenario where the wireline networks could be replaced by UC federation. "The Implications of UC as a Cloud Service" speculates whether the operation of communication networks will be taken over by the emerging UC cloud vendors.