OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [bdxr] RE: Update on IEEE P2302 Intercloud WG


Hi Roger

Thanks for sharing this. Having read through the IEEE document I agree with you that the term "Intercloud" cannot be used interchangeably here. The IEEE document speaks specifically about cloud computing, where I think we use the term "cloud" in a more broad sense referring to networks and infrastructures in general.

I think it's a very interesting document, especially because the question (at a very high level) they are trying to solve is somewhat similar to ours: "How do I reach something on a different cloud or network from where I am". However, their more specific requirements of being able to share specific computing resources (CPU, storage, memory...) across individual cloud computing environments seem to me to have a very different complexity than our requirements.

The overall concept of having "Intercloud Root Providers" (chapter 5.1) as shared registries between "clouds" seem to map fairly well with the SML concept, though they want the root providers to host "Resource Catalogues" (which I guess can be compared with SMP) and having these catalogues replicated between roots, which is fundamentally different from the multilayered SMLP design. I see the SMP (as a concept) more coupled with the gateway than with the SML, and I am not sure we would have an interest in having the entire metadata "catalogues" replicated between clouds. As I understand the document, they want to create a new specification for the "Intercloud Roots" and having the roots "governed in a similar way in which DNS and Top Level Domains by an organization such as ISOC or ICANN.". If our requirements can be covered by existing standards such as DNS, then I think we may be better off continuing that direction. It will in any case be very interesting to the IEEE project and to identify potential common denominators and reusable architectures.

Best regards,

Kenneth


From: Roger Bass <robass1@earthlink.net>
Date: Thursday, June 7, 2012 12:45 PM
To: <bdxr@lists.oasis-open.org>
Subject: [bdxr] RE: Update on IEEE P2302 Intercloud WG

All,

 

I just participated in the latest bi-monthly meeting of the IEEE Intercloud WG P2302, and wanted to send this update.  (There is a separate WG P2301 effort on Cloud Portability and Interoperability Profiles – less active for now).  Thinking back to some discussions we had around the new BDXR charter, I think there’s skepticism on both sides as to how close the relationship is between this TC’s efforts and theirs (or rather, whether “Intercloud” terminology makes sense for us at all).  And it’s certainly true that the IEEE efforts are more focused at lower-level “cloud / network” layer activities, e.g. VM portability.

 

That said, it does seem to me that the elements of their architecture may map fairly exactly onto ours.  The specific requirements clearly differ for at least some of those layers or elements.  But I wonder whether there might not be a basis for convergence at some point.  For the Discovery layer in particular, and perhaps also the Trust and Dialog (aka Connect) layers, I wonder if there might not even be a basis for convergence sooner rather than later.  On Profiles and Messaging, any convergence seems probably further away.

 

The IEEE efforts are still at a fairly early stage, and are soliciting volunteers to take ownership of (or at least contribute to) different sections of their draft standard document.  I will upload that document to the TC repository, but have copied below the relevant sections from the table of contents.  Without making any commitments, I have mentioned to the IEEE WG the possible overlaps I see on section 5, and sections 6.6-6.10.  (The ‘Connect’ protocol may further relate to 6.2-6.5, but perhaps only if the salient features can be separated from the underlying protocol, since P2302 seems fairly committed to XMPP).

 

Consideration of any formal liaison would seem premature.  But some TC members might like to review the P2302 draft document.  And as our work in BDXR progresses, I look forward to helping make further connections between the two, as may be appropriate.

 

Best,

Roger

 

 

 

IEEE P2302™/D0.2 Draft Standard for Intercloud Interoperability and Federation (SIIF)

 

EXTRACT FROM TABLE OF CONTENTS

 

4. Cloud to Cloud Interoperability and Federation - Intercloud ..................................................................... 2

4.1 Introduction to Intercloud - Background and Concept ........................................................................ 2

4.2 Introduction to Intercloud - Topology and Protocols........................................................................... 3

 

5. Intercloud Topology Elements ................................................................................................................... 4

5.1 Intercloud Root .................................................................................................................................... 4

5.2 Intercloud Exchanges........................................................................................................................... 5

5.3 Intercloud Capable Individual Clouds – Intercloud Gateways ............................................................ 6

 

6. Intercloud Protocols and Interoperability ................................................................................................... 6

6.1 Base Intercloud Protocols - XMPP ...................................................................................................... 7

6.2 Intercloud Protocols Services Framework – XEP 0244 and XWS4J................................................... 8

6.3 Intercloud Protocols Encryption and Authentication – TLS and SASL and SAML ............................ 8

6.4 Intercloud Exchange Service Invocation – XMPP .............................................................................10

6.5 Intercloud Protocol - Presence & Dialog with XMPP ........................................................................11

6.6 Intercloud Trust Model .......................................................................................................................12

6.7 Intercloud Identity and Access Management – SAML, XACML ......................................................13

6.8 Intercloud PKI Certificates Deployment ............................................................................................15

6.9 Intercloud Exchange Service Discovery – XMPP Based RDF and SPARQL approach ....................16

6.10 Intercloud Resources Catalog Deployment ......................................................................................22

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]