Re: [sop] [dc] Service Orchestration Protocol

"Ashish Dalela (adalela)" <> Fri, 17 February 2012 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19DB821E8040; Thu, 16 Feb 2012 18:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.058
X-Spam-Status: No, score=-7.058 tagged_above=-999 required=5 tests=[AWL=3.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3GO9AP29he53; Thu, 16 Feb 2012 18:32:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9483321E8060; Thu, 16 Feb 2012 18:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=18003; q=dns/txt; s=iport; t=1329445946; x=1330655546; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=pa8CrZ59MEtDI/vncnA1p0LZuPkDjWZhbnXsMJYdcvo=; b=bv31MpBBqPj7EXVyqXdQpSiUOjcQvUjsoN+gNQhXlIV46uptL6z1izf5 t91BY0BOnhIKvxskD/rpnCtjC2wREkBiLFMiuOVFdK8unS/5FPu/D3GIq RnPxGeiDur7QozwmM7Pthr+OA5cz2jL+VHd8q9Y2FrrzwU4aAlruDNAUe c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.73,433,1325462400"; d="scan'208,217";a="5753579"
Received: from (HELO ([]) by with ESMTP; 17 Feb 2012 02:32:23 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q1H2WNwt000575; Fri, 17 Feb 2012 02:32:23 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 08:02:23 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCED1C.61273991"
Date: Fri, 17 Feb 2012 08:02:22 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [dc] Service Orchestration Protocol
Thread-Index: Aczs7ZfZDYEr3/UNTYaJqjiWS03dvQAKzDzQ
References: <> <>
From: "Ashish Dalela (adalela)" <>
To: "Bhumip Khasnabish" <>
X-OriginalArrivalTime: 17 Feb 2012 02:32:23.0598 (UTC) FILETIME=[616814E0:01CCED1C]
Subject: Re: [sop] [dc] Service Orchestration Protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Feb 2012 02:32:39 -0000



Thanks, I'm aware of this draft. We should discuss it on the SOP alias
as not to clutter everyone's email with a topic that may not be of
interest. I'm cross posting this to SOP alias for now.


One of things that the first draft describes is limitations of HTTP (and
by implication web-services) for doing cloud - HTTP does not have
constructs to do service discovery, pub-sub, commit-cancel, transaction
forking, interactive prompts, etc. These capabilities are
service-independent (applicable to all services) and very important to
build complex, multi-tiered, or cross-domain services. 


So, we did not want to add just a new content-type to HTTP, and layer
basic capability into the controller application. The idea here is that
if there are service independent capabilities, they should be part of a
basic protocol scheme, which can be used by every type of service. But
we preserved the text-based nature of well-known L7 protocols - SIP,
HTTP, SMTP, etc. 


To the specific issue of broker, you might want to refer to the
architecture draft, where we described different types of brokers (we
call them proxies). The functionality in the broker differs depending on
where you place the broker - in the service edge, customer edge,
provider edge, etc. We expect that different domains (compute, storage,
network ..) will have different domain controllers. You still need to
find an interoperable scheme to stitch these domain controllers.


Thanks, Ashish


From: Bhumip Khasnabish [] 
Sent: Friday, February 17, 2012 2:27 AM
To: Ashish Dalela (adalela)
Subject: Re: [dc] Service Orchestration Protocol


Hello Ashish,


There is also a Cloud Service Broker draft 







On Thu, Feb 16, 2012 at 12:06 PM, Ashish Dalela (adalela)
<> wrote:



This may not be completely relevant to the DC topic, but thought that
some of you might be interested in it.


We have a few drafts posted on a "Service Orchestration Protocol", with
the intent to enable cloud interoperability. - talks about
why we need a protocol, a.k.a. requirements - describes
the use-cases and network deployments with the protocol - describes the
protocol's messages - describes scheme for
service naming, workflows, etc. - describes some
message flows


A discussion alias is setup
for you to participate in case you find it interesting.


Thanks and look forward to discussing there.




dc mailing list