Exploring the Many Flavors of UC Federation
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.