Tuesday, March 30, 2010

Thinking about Intercloud Topology, and Using XMPP as a transport in Intercloud Protocols

I have been thinking about the topology for the Intercloud. There are Intercloud Exchanges (analogous to Internet Exchanges and Peering Points) where clouds can interoperate, and there is an Intercloud Root, containing services such as Naming Authority, Trust Authority, Directory Services, and other “root” capabilities. It is envisioned that the Intercloud root is of course physically not a single entity, a global replicating and hierarchical system similar to DNS. All elements in the Intercloud topology contain some gateway capability analogous to an Internet Router, implementing Intercloud protocols in order to participate in Intercloud interoperability. Let's call these Intercloud Gateways.

The Intercloud Root and Intercloud Exchanges would facilitate and mediate the initial Intercloud negotiating process among Clouds and all these elements. It is this Presence and Messaging capability that's got me thinking, just what protocol would we use for that?

If you think about it, cloud instances must be able to dialog with each other. One cloud must be able to find one or more other clouds, which for a particular interoperability scenario is ready, willing, and able to accept an interoperability transaction with and furthermore, exchanging whatever subscription or usage related information which might have been needed as a pre-cursor to the transaction. Thus, an Intercloud Protocol for presence and messaging needs to exist which can support the 1-to-1, 1-to-many, and many-to-many Cloud to Cloud use cases.

Extensible Messaging and Presence Protocol (XMPP) is exactly such a protocol. XMPP is a set of open XML technologies for presence and real-time communication developed by the Jabber open-source community in 1999, formalized by the IETF in 2002-2004, continuously extended through the standards process of the XMPP Standards Foundation. XMPP supports presence, structured conversation, lightweight middleware, content syndication, and generalized routing of XML data. XMPP root services would be located in the Intercloud Root in the topology explained above.

XMPP defines protocols for communicating between groups of entities which register with an XMPP server. Registration is dynamic and provides the basis for Presence. In a large implementation, such as the global Intercloud envisioned herein, XMPP servers are connected together. This is identical to the way service providers connect XMPP servers together already supporting cross-domain Instant Messaging. In this way, XMPP facilitates both presence and many-to-many messaging across service provider domains. XMPP messages are extensible, and can be used to carry messages of different types. For example, an XMPP Message can carry Instant Messaging (IM) type traffic. We could be using a Cloud extension to XMPP.

Deepak Vij and I were thinking about all this, and we put some detail into a whole design for XMPP as a core transport in Intercloud. We wrote a paper and posted it on the CSP Site. Check it out. It seems, XMPP might be just what the doctor ordered for Intercloud.

2 comments:

  1. Nice article i read your full article and its a more knowledgeable for everyone and please share more information related to software.For searching job in it sector please click here- it jobs

    ReplyDelete
  2. I’m going to mosey on over to your blog and take a look under the hood. I’m sure it will be as good as this post.Absolutely great post here. It has a lot of key elements that truly makes it work.
    XMPP

    ReplyDelete