Exploring the Many Flavors of UC Federation

Exploring the Many Flavors of UC Federation

By Andy Zmolek July 25, 2010 4 Comments
Andy Zmolek PNG
Exploring the Many Flavors of UC Federation by Andy Zmolek

As federation concepts have entered the unified communications landscape over the past few years, the notion of what is actually meant by the term has been hard to pin down. Within the Instant Messaging world (now dominated by XMPP, which has specific standards for federation among XMPP servers), federation is synonymous with multi-vendor interoperability while federation in the Microsoft OCS realm is typically associated with connecting one enterprise OCS deployment to another. Peering providers like to associate federation with brokered communications while some enterprises expect all federated relationships to be direct to their peers. Sometimes it can feel like federation is everything to everyone, like the term “cloud computing” these days (or the term “soft switch” back in the early days of VoIP).

It’s time we had a more complete vocabulary for federation in the UC community, and with that in mind I’d like to suggest an approach for disambiguation among all these flavors of federation. Then I’ll give some examples of each and offer a bit of commentary in the process. Let’s start with intra-domain vs. inter-domain federation, and then divide the latter into direct, brokered, and opportunistic federation.

Intra-Domain Federation: As the name suggests, this refers to federation within an organization. This kind of federation might be between two UC vendors that provide different UC services to the same user population (potentially using the same SIP address space) or it could be between sub-domains or separate organizational units within an enterprise (or equivalent). At some level in the organization hierarchy, all intra-domain federation falls under a common business leader (although in the worst case scenario one might have to go all the way to the top to get to that common leadership location).

Inter-Domain Federation: This kind of federation takes place between two enterprises (or their equivalent). Most people have inter-domain use cases in mind when they use the term “federation” even if they’re not conscious of it.

Direct Federation: Sometimes known as direct trunking or direct peering depending on the context, this type of federation is directly set up and controlled by the participants themselves. In general, carriers and brokers are not involved. All trust relationships are managed by the participants.

Brokered Federation: When a middleman is required to establish a federation relationship, this type of federation is in play. What’s brokered specifically may vary, and the federation broker can play a significant role in managing trust relationships among federation partners.

Opportunistic Federation: This class of federation is more recent, and today the only known example is found in the VIPR protocol (Verification Involving PSTN Reachability) that Cisco has implemented in their Intercompany Media Engine and proposed as an IETF standard jointly with Skype. What makes VIPR unique is that it uses voice calls over the PSTN to identify and validate potential federation opportunities. Unlike direct federation, relationships are not directly provisioned by participants for opportunistic federation. No broker or other middleman is required for ongoing federation, either.

Let’s look at a couple of real-world examples of each. Microsoft OCS federation is typically direct, inter-domain federation between two enterprises running OCS (though some 3rd-party products do offer intra-domain multi-vendor federation solutions through proprietary Microsoft interfaces). ENUM-based peering solutions on the other hand offer federation in a brokered inter-domain flavor. Therefore, we know immediately that each solution will offer a fundamentally different answer to any given UC federation use case, and some use cases may not be addressed in one or the other.

Is any one of these flavors the “best” form of UC federation? In general, the answer is an emphatic “no” but when looking at the business needs of a specific enterprise it’s another story. A careful look at what’s going to work best for a given UC deployment strategy can identify the federation flavor(s) that make the most sense for a given enterprise given their business needs and goals. That’s a topic for a future column, but suffice it to say that whether you’re customer or vendor of UC technologies it’s a good idea to know what flavors of federation make the most sense for the development of your real-world UC story.  


4 Responses to "Exploring the Many Flavors of UC Federation" - Add Yours

Rob Ingram 7/26/2010 7:11:50 AM

Andy 2 of things I don't agree with here. 1. XMPP is not the dominant force in IM - far from it by any market measure. There simply is not yet a critical mass of deployment in use in consumer or enterprise IM. 2. XMPP is not a standard by measure of the IETF. SIP simple is the only standards body endorsed interop standard. I do agree on one point in that more needs to be done in this inter-domain space. However vendors need to put aside their desire to contol interop by not setting up side forums that serve a subset of the market and their own commercial gains. Rob Ingram Senior Product Manager, IBM Lotus Sametime
Farzin Shahidi 7/28/2010 3:42:21 PM

NextPlane (www.nextplane.net) is the only federation vendor that addresses inter-domain, intra-domain, and brokered federation types. We cover Presence, IM, Multi-user chat and just released voice federation capabilties as well.
Global 2000 companies are using either The NextPlane Federation Server or subscribing to the NextPlane UC Federation Service.
NextPlane supports LCS, OCS, Sametime, Jabber, CUPS, and Google Apps.
Farzin Shahidi
NextPlane, Inc.
Duncan Blake 11/7/2010 7:45:01 PM

I have to agree with Rob that XMPP is not dominant in either the consumer or enterprise IM spaces.

I'd also like to draw attention to the fact that the Microsoft UC family of products has offered Open Federation (what you are calling "Opportunistic Federation") and Clearing House ("Brokered Federation") models since at least LCS 2005.
Andy Zmolek 11/9/2010 8:39:06 AM

XMPP and SIMPLE both have broad deployment, and it's certainly understandable why vendors who have chosen the latter might take issue with my characterization of XMPP. To be sure, there had been something of a religious war going on for years between the two camps. But it's not often I see much new happening in the world of SIMPLE these days, while it seems like every few months I run into someone else using XMPP for something new and interesting. In any case, the point of the article was federation and in fact it's possible to federate both protocols. SIMPLE federation isn't as well defined at this point, but there is work in the IETF underway to address that.

As I mentioned in the article, Microsoft has offered a type of federation with it's products for some time, but if anything it's model is direct federation as it requires administrators on both sides to directly enable and configure that federation. Clearinghouse federation is generally used for subdomains but a few service providers have done some very basic brokering with it despite its limitations - it's an all or nothing proposition for those that use a clearinghouse, so many large enterprise customers are uncomfortable opening the floodgates to the kind of security challenges seen every day in corporate email.

To Leave a Comment, Please Login or Register

BC Summit 2016 UC Alerts
UC Blogs
UC ROI Tool RSS Feeds