Network Working Group A. Dalela
Internet Draft Cisco Systems
Intended status: Standards Track M. Hammer
Expires: July 2012 January 4, 2012
SOP Message Flows
draft-dalela-sop-flows-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 4, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Dalela Expires July 4, 2012 [Page 1]
Internet-Draft SOP Message Flows January 2012
Abstract
This document describes the Service Orchestration Protocol (SOP)
message flows for some important service orchestration scenarios. The
flows contain complete packet information including both SOP and
Service Description Framework (SDF) payloads. The message flows in
this document are by no means exhaustive, but they carry sufficient
information using which other flows can be easily constructed. The
deployment scenarios for services are varied, and it is not possible
to cover every possible scenario. Nevertheless, those flows will
follow closely the information given in this document.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Terms and Acronyms.............................................3
4. Network Discovery..............................................4
4.1. Service Node to Proxy Discovery...........................4
4.2. User to Proxy Discovery...................................7
4.3. Proxy to Proxy Discovery.................................11
4.4. WS to Proxy Discovery....................................12
5. Service Provisioning..........................................13
6. Service Deletion..............................................19
7. Service Update................................................20
8. Service Mobility..............................................22
8.1. Stateful Service Mobility................................22
8.2. Stateless Service Mobility...............................26
9. Security Considerations.......................................28
10. IANA Considerations..........................................28
11. Conclusions..................................................28
12. References...................................................28
12.1. Normative References....................................28
12.2. Informative References..................................28
13. Acknowledgments..............................................28
Dalela Expires July 4, 2012 [Page 2]
Internet-Draft SOP Message Flows January 2012
1. Introduction
This document describes orchestration message flows using the Service
Orchestration Protocol (SOP) messages and the Service Description
Framework (SDF) payloads. The SOP document [SOP] describes service-
independent messages and headers. The SDF document [SDF] describes a
framework to construct service-specific information payloads. The
present document combines SOP messages and SDF payloads into end-to-
end message flows for service orchestration.
This document also complements the SOP requirements [REQT] and SOP
architecture [ARCH] documents that cover interoperability and
deployment scenarios respectively. The flows covered in this document
apply to those interoperability and deployment scenarios.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terms and Acronyms
The key words Provider, Vendor, User, Orchestration, Client, in this
document have the same meaning as defined in SOP requirements [REQT].
The key words Proxy, Workflow Server (WS), Service Node (SN),
Workflow Anchor (WA), Workflow Branching, in this document have the
same meaning as defined in SOP architecture [ARCH].
The key words Service Description Framework (SDF), Service Domain
Name (SDN), SDN Attributes, Vendor Specific Domains (VSD) in this
document have the same meaning as defined in SDF description [SDF].
All messages, timers, counters, message headers and their values used
in this document are described in the SOP document [SOP].
Dalela Expires July 4, 2012 [Page 3]
Internet-Draft SOP Message Flows January 2012
4. Network Discovery
SOP discovery procedures involve multiple kinds of discoveries: (a)
SN to Proxy discovery, (b) User to Proxy discovery, (c) Proxy to
Proxy discovery, and (d) WS to Proxy discovery.
4.1. Service Node to Proxy Discovery
The SOP message flow for service discovery is shown below.
+--------+ +--------+ +--------+
| SN | | Proxy | | WS |
+--------+ +--------+ +--------+
| DISCOVER | |
|----(Proxy for svc X?)----->| |
| | |
| ADVERTISE | |
|<----(Proxy for svc X)------| |
| | |
| REGISTER | |
|------(SN is usable)------->| |
| | |
|<-------- 200 OK -----------| |
| | |
| PUBLISH | |
|-----(Update on Svc X)----->| PUBLISH |
| |-----(Update on Svc X)---->|
| | |
| |<---------200 OK-----------|
|<-------- 200 OK -----------| |
| | |
Figure-1: Message Flow for Service Node Discovery
On initialization, a SN will send out a DISCOVER message asking for a
Proxy to which it can send service information. The DISCOVER MUST
carry the Service Domains that the SN supports. A Proxy will respond
only for Domain Names that it is configured to Proxy. This allows
multiple kinds of domain specific Proxies to exist in a network,
orchestrating specific kinds of services only. DISCOVER is optional
and should be sent if an ADVERTISE matching the service has not been
received. It will use the IP broadcast address.
DISCOVER 1 SOP/1.0
From: default@default.com
Dalela Expires July 4, 2012 [Page 4]
Internet-Draft SOP Message Flows January 2012
Via: SOP/1.0/UDP default@default.com;branch=k9DjR5lbcw
Timestamp: 1285162130
Sequence-ID: 1 DISCOVER
Content-Type: application/sdf; charset=utf-8
Content-Length: 100
In above message, SN supports the iaas.compute domain. It sends
DISCOVER to find any Proxies that may proxy for this domain.
On initialization, or on the receipt of a DISCOVER message, or on the
expiry of the Advertise-Timeout, whichever comes earlier, the Proxy
SHALL send an ADVERTISE message indicating its presence and readiness
to proxy for some service domains. The ADVERTISE will be unicast if
sent to a specific SN after receiving a DISCOVER from it. Otherwise,
the DISCOVER SHOULD be broadcast to all SN in the network. The
ADVERTISE MUST indicate service Domain Names so that only SNs with
those capabilities need to take cognizance of it.
ADVERTISE 1 SOP/1.0
From: default@p.provider.com
To: default@default.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9DjR5lbcw
Timestamp: 1285162132
Sequence-ID: 13224 ADVERTISE
Registration-Timeout: 1000
Advertisement-Timeout: 2500
Commit-Timeout: 30
Cancel-Timeout: 15
Publish-Timeout: 500
Subscribe-Timeout: 5000
Retry-Count: 3
Content-Type: application/sdf; charset=utf-8
Content-Length: 100
The ADVERTISE message also has the function of globally configuring
all SNs under its control by sending out Timer and Counter
information in the message itself. Each transaction can subsequently
override these values for that transaction alone. Unless overridden
in those requests, these values apply for all transactions.
Dalela Expires July 4, 2012 [Page 5]
Internet-Draft SOP Message Flows January 2012
On receiving the ADVERTISE, a SN MAY respond with a REGISTER, if the
domains match. The REGISTER would be sent after receipt of the
ADVERTISE if the SN has not already registered, or upon the expiry of
the Registration-Timeout, whichever comes first. REGISTER identifies
a SN to the Proxy and acts as heartbeat between Proxy and SNs.
REGISTER 1 SOP/1.0
From: default@default.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@default.com;branch=k9DjR5lbcw
Sequence-ID: 1 REGISTER
Transfer-Mode: service-driven
Node-Type: service-node
Content-Type: application/sdf; charset=utf-8
Content-Length: 100
In the example above, the REGISTER is being sent for the first time
to the Proxy. The SN does not yet have an identity. The "From" header
therefore has the default SOP address. For subsequent REGISTER, the
identity assigned to the SN in prior REGISTER MUST be used.
On receiving a REGISTER and after validating that the SN belongs to
the domain that the Proxy is configured for, the Proxy SHOULD respond
with a 200 OK, indicating a successful registration. If the REGISTER
had not indicated a unique name (the From field), the Proxy response
MUST contain a Service-ID header, assigning a user-name to the
service. The SN MUST use the assigned Service-ID henceforth, and the
Proxy SHALL reject all requests that do not match the assigned
Service-ID name (the "default" name is always admitted). The Proxy
SHALL match the name of the requestor against its IP Address that was
used during REGISTER for all subsequent requests.
200 OK 1 SOP/1.0
From: default@p.provider.com
To: default@4357254.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9DjR5lbcw
Sequence-ID: 1 REGISTER
Service-ID: 4357254.provider.com
Upon a successful registration, the SN SHALL send a PUBLISH to the
Proxy providing details about available services. While the REGISTER
Dalela Expires July 4, 2012 [Page 6]
Internet-Draft SOP Message Flows January 2012
is sent periodically, the PUBLISH SHOULD be sent only when service
availability changes or after the first registration or when the
Publish-Timeout expires, whichever comes first. A SN SHOULD send
PUBLISH after service creation or deletion to update the Proxy about
its new capabilities (which may be increased or decreased).
PUBLISH 1 SOP/1.0
From: default@4357254.provider.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@4357254.provider.com;branch=k9DjR5lbcw
Sequence-ID: 13432 PUBLISH
Distance: 1
Node-Type: service-node
Content-Type: application/sdf; charset=utf-8
Content-Length: 513
The PUBLISH message MUST list capabilities for its domains. Upon
receipt of the PUBLISH, the Proxy MUST forward it to the appropriate
WS (the WS MUST have prior done a SUBSCRIBE for specific domains, see
Section 4.4. ). This allows the WS to know of the SN's capabilities
which can then be utilized in service allocations. After successfully
updating its service repository, the WS SHOULD respond with a 200 OK.
The Proxy SHALL forward the 200 OK back to the SN.
200 OK 1 SOP/1.0
From: default@p.provider.com
To: default@4357254.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9DjR5lbcw
Sequence-ID: 13432 PUBLISH
4.2. User to Proxy Discovery
Clients MAY be configured with Proxy addresses (e.g. if Client
connect to Proxies over the Internet where broadcasting is
impractical). The ADVERTISE from the Proxy is still useful because it
downloads network configuration of Timers, Counters, etc. Such a
Client SHOULD initiate the Proxy discovery by sending a unicast
Dalela Expires July 4, 2012 [Page 7]
Internet-Draft SOP Message Flows January 2012
DISCOVER to the Proxy. The ADVERTISE in response will also be
unicast. Subsequent REGISTER is identical to service discovery.
The message flow for user discovery differs from that of service
discovery in that a user does not send a PUBLISH to advertize its
capabilities. Instead, the user sends a SUBSCRIBE to the Proxy to
express its interest in certain types of services.
The SUBSCRIBE message SHOULD be sent by the User after a new
registration, or when the interest list of services changes, or upon
the expiry of Subscribe-Timeout, whichever comes first. SUBSCRIBE is
a request-response sequence and the Proxy SHALL send a 200 OK if the
SUBSCRIBE matches the service capabilities of the Proxy. In case a
Proxy's service capabilities change, the Proxy MUST send out a new
ADVERTISE listing new domain capabilities. If those capabilities are
of interest to a User, it MAY send a new SUBSCRIBE expressing
interest in receiving information about those services.
+--------+ +--------+ +--------+
| User | | Proxy | | WS |
+--------+ +--------+ +--------+
| DISCOVER | |
|---(Proxy for Domain X?)--->| |
| | |
| ADVERTISE | |
|<---(Proxy for Domain X)----| |
| | |
| REGISTER | |
|----(User is available)---->| |
| | |
|<-------- 200 OK -----------| |
| | |
| SUBSCRIBE | |
|---(Updates on Domain X)--->| SUBSCRIBE |
| |---(Updates on Domain X)-->|
| | |
| |<---------200 OK-----------|
|<-------- 200 OK -----------| |
| | PUBLISH |
| PUBLISH |<--(Updates on Domain X)---|
|<---(Updates on Domain X)---| |
| | |
|--------- 200 OK ---------->| |
| |----------200 OK---------->|
Figure-2: Message Flow for User Discovery
Dalela Expires July 4, 2012 [Page 8]
Internet-Draft SOP Message Flows January 2012
A SUBSCRIBE message SHOULD have a list of service domains the User is
interested in. If a SUBSCRIBE is sent without any specific domain,
the Proxy SHALL interpret it as an interest in all domains. The User
must also mention the Node-Type as a "service-client".
SUBSCRIBE 1 SOP/1.0
From: default@ws.provider.com
To: default@p.provider.com
Via: SOP/1.0/UDP default@ws.provider.com;branch=k9DjR5lbcw
Exchange: 43shXui7236
Timestamp: 1285162130
Sequence-ID: 1 SUBSCRIBE
Node-Type: service-client
Content-Type: application/sdf; charset=utf-8
Content-Length: 154
workflow description
taskgroup description
The Workflow contains a list of tasks, domains and attributes, that
the user needs to populate. The WS can mask one or more of the tasks,
Dalela Expires July 4, 2012 [Page 10]
Internet-Draft SOP Message Flows January 2012
domains and attributes of a Workflow that are visible to a user. In
effect, the user is only allowed to specify certain portions of the
Workflow, and leave the rest to the WS. The Workflow can be viewed as
an API exposed to the user where the User is allowed to fill up
certain number of parameters before sending to Proxy. If the User
accepts the Workflow it SHOULD send a 200 OK response.
200 OK 1 SOP/1.0
From: consumer@customer.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@customer.com;branch=k9DjR5lbcw
Sequence-ID: 1 PUBLISH
4.3. Proxy to Proxy Discovery
+--------+ +--------+ +--------+
| Proxy | | Proxy | | WS |
+--------+ +--------+ +--------+
| DISCOVER | |
|---(Proxy for Domain X?)--->| |
| | |
| ADVERTISE | |
|<---(Proxy for Domain X)----| |
| | |
| REGISTER | |
|----(User is available)---->| |
| | |
|<-------- 200 OK -----------| |
| | |
| SUBSCRIBE | |
|---(Updates on Domain X)--->| SUBSCRIBE |
| |---(Updates on Domain X)-->|
| | |
| |<---------200 OK-----------|
|<-------- 200 OK -----------| |
| | PUBLISH |
| PUBLISH |<--(Updates on Domain X)---|
|<---(Updates on Domain X)---| |
| | |
|--------- 200 OK ---------->| |
| |----------200 OK---------->|
Figure-3: Message Flow for Proxy Discovery
SOP network setup requires Proxies to discover other Proxies. This
discovery procedure is nearly identical to that for Users. Each Proxy
Dalela Expires July 4, 2012 [Page 11]
Internet-Draft SOP Message Flows January 2012
SHALL send a SUBSCRIBE to other Proxies that it is configured to
communicate with, along with service domains that it is interested
in, in much the same way as the User subscribes for services. The
Node-Type header for Proxies should be set to "service-proxy". The
subscribing Proxy is the Client for receiving service information.
The PUBLISH accordingly can forward to that Proxy information about
the Workflows it owns, about the services its managing and details or
summaries of current capacities (depending on configured policies).
4.4. WS to Proxy Discovery
+--------+ +--------+
| WS | | Proxy |
+--------+ +--------+
| DISCOVER |
|---(Proxy for Domain X?)--->|
| |
| ADVERTISE |
|<---(Proxy for Domain X)----|
| |
| REGISTER |
|-----(WS is available)----->|
| |
|<-------- 200 OK -----------|
| |
| SUBSCRIBE |
|<--(Updates on Domain X)----|
| |
|--------- 200 OK ---------->|
| |
| PUBLISH |
|----(Updates on Domain X)-->|
| |
|<-------- 200 OK -----------|
| |
Figure-4: Message Flow for WS Discovery
A Proxy SHALL send its interest domains through an ADVERTISE. If the
WS finds a match, it SHALL send a REGISTER to the Proxy. In the
REGISTER, the Node-Type should be set as "workflow-server". This
informs the Proxy to send a SUBSCRIBE to the WS for interested
service domains. In the SUBSCRIBE, the Proxy SHALL indicate its
domains of interest. If one or more such domains match, the WS SHOULD
send a 200 OK, listing the matching domains. After this the WS SHOULD
forward matching Workflows to the Proxy.
Dalela Expires July 4, 2012 [Page 12]
Internet-Draft SOP Message Flows January 2012
Workflows in the WS SHOULD be configured with Anchors against each
Workflow. This allows a WS to determine which Workflows to forward to
a Proxy. The Anchors SHOULD be mentioned as the "anchor" attribute in
the element. The "anchor" attribute informs the service
network where the workflow is anchored. When a Proxy forwards a
Workflow to another Proxy, it MAY retain the Anchor information. A
Proxy MAY remove the "anchor" attribute if forwarding the Workflow
outside an administrative domain to hide the service network's
topology. However, the Proxy MUST maintain Anchor information
internally to know which Proxy to send the information to.
Each Workflow has a "distance" attribute. This attribute must be
incremented by 1 every time a Proxy forwards a Workflow to another
Proxy. This will allow the Proxies to build a distance-vector routing
mechanism to reach a Workflow Anchor. A Proxy MAY be configured with
a maximum distance beyond which it will not forward any Workflows. In
forwarding requests to a Workflow, a Proxy may use the shortest
distance or other routing policies to forward requests.
5. Service Provisioning
+------+ +------+ +-------+ +-------+ +------+
| SN1 | | SN2 | | User | | Proxy | | WS |
+------+ +------+ +-------+ +-------+ +------+
| | | | |
| | | WORKFLOW | |
| | |----------->| |
| | | 100 TRYING | |
| | |<-----------| GET (workflow) |
| | | |------------------>|
| | | | 200 OK (workflow)|
| | | |<------------------|
| | CREATE (task) | |
| |<------------------------| GET (task) |
| | | |------------------>|
| | | | 200 OK (task) |
| CREATE (task) | |<------------------|
|<----------------------------------| |
| | | | GET (task) |
| | | |------------------>|
| | | | 200 OK (task) |
| | | |<------------------|
| | 200 OK | |
| |------------------------>| |
| 200 OK | | | |
|---------------------------------->| |
| | | | |
Dalela Expires July 4, 2012 [Page 13]
Internet-Draft SOP Message Flows January 2012
| | COMMIT (task) | |
| |<------------------------| |
| COMMIT (task) | | |
|<----------------------------------| |
| | 200 OK | |
| |------------------------>| |
| 200 OK | | | |
|---------------------------------->| |
| | | | COMMIT (workflow) |
| | | |------------------>|
| | | | 200 OK |
| | | |<------------------|
| | | 200 OK | |
| | | (workflow) | |
| | |<-----------| |
| | | | |
| | PUBLISH (svc) | |
| |------------------------>| |
| | 200 OK | |
| |<------------------------| |
| | | | |
| | PUBLISH (svc) | |
|---------------------------------->| |
| | 200 OK | | |
|<----------------------------------| |
| | | | |
Figure-5: Message Flow at Service Provisioning
A User initiates a workflow by sending the WORKFLOW message.
WORKFLOW 1 SOP/1.0
From: consumer@customer.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.customer.com;branch=k9DjR5lbcw
Sequence-ID: 5 WORKFLOW
Workflow-Name: gTyuI82Zx@provider.com
The User indicates a Workflow-Name that MUST already exist. This
message MAY contain a detailed specification of the Workflow Tasks
and parameters. As the WORKFLOW request traverses the network towards
the Workflow Anchor, the request MAY be modified in transit by
intermediate Proxies. However, the Workflow MUST NOT begin execution
until it reaches the Workflow Anchor. This means that the request
must not be branched into Tasks until reaching the Anchor.
Dalela Expires July 4, 2012 [Page 14]
Internet-Draft SOP Message Flows January 2012
Each Proxy SHOULD look up the source of the Workflow-Name and forward
it to another Proxy. The Workflow Anchor SHOULD send a 100 Trying
response to indicate to the User that it has received the request and
is processing it. Orchestration requests may take some time to
process, and the 100 Trying message will keep the User posted.
100 TRYING 1 SOP/1.0
From: default@p.provider.com
To: consumer@customer.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9DjR5lbcw
Sequence-ID: 5 WORKFLOW
Workflow-Name: gTyuI82Zx@provider.com
In case the Workflow-Name is available with a known WS, the Anchor
MUST send a GET request to the WS asking it to detail the Workflow.
If the original request was received with a detailed Workflow
description, the Anchor MUST forward the description to the WS. The
WS SHOULD use the received Workflow as an input to determine a
completed and finalized Workflow.
GET 1 SOP/1.0
From: default@p.provider.com
To: default@ws.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9oluElbcw
Sequence-ID: 286 WORKFLOW
Workflow-Name: gTyuI82Zx@provider.com
Query-Type: workflow-name
Requestor: consumer@customer.com
The GET copies requestor name into the Requestor header. This will
allow the WS to validate if the indicated workflow is available for
the Requestor and apply user-specific policies if any. It will then
return a workflow description comprising of individual tasks.
200 OK 1 SOP/1.0
From: default@ws.provider.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP ws@p.provider.com;branch=cw8gtrB56m
Sequence-ID: 286 GET
Workflow-Name: gTyuI82Zx@provider.com
Workflow-ID: 68743693
Query-Type: workflow-name
Requestor: consumer@customer.com
Content-Type: application/sdf; charset=utf-8
Dalela Expires July 4, 2012 [Page 15]
Internet-Draft SOP Message Flows January 2012
Content-Length: 542
workflow description
taskgroup description
At this point, the WS has created an instance of a Workflow,
customized for this particular request. This instance is referenced
by the Workflow-ID "68743693". It carries a detailed configuration of
the VM, which is referenced by a Task-ID = "67439375". The WS has
allocated a server "4357254.provider.com" for the "CREATE" task. The
Proxy SHOULD now send a CREATE request to the selected server.
CREATE 1 SOP/1.0
From: default@p.provider.com
To: default@4357254.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9DjR5lbcw
Sequence-ID: 134 CREATE
Task-ID: 67439375
Workflow-Server: ws.provider.com
Requestor: consumer@customer.provider.com
The above CREATE request is sent by the proxy "p.provider.com" to a
server "4357254.provider.com". The CREATE informs the receiver that
there is a Task-ID "67439375" pending at "ws.provider.com". The
receiver should obtain that task and execute it. The Requestor field
describes the user for whom the request is proxied. The receiver
SHOULD download the Task description from the Workflow Server,
identified by the Task ID, using the GET request.
GET 1 SOP/1.0
From: default@4357254.provider.com
To: default@ws.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@4357254.provider.com;branch=cw8gtrB56m
Sequence-ID: 390 GET
Query-Type: task-id
Task-ID: 67439375
Dalela Expires July 4, 2012 [Page 16]
Internet-Draft SOP Message Flows January 2012
The Workflow Server SHOULD forward a Task Description to the
requestor, as shown below. The Task describes a workflow to be
executed by the receiver, pertaining to a domain "iaas.compute".
200 OK 1 SOP/1.0
From: default@ws.provider.com
To: default@4357254.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@ws.provider.com;branch=cw8gtrB56m
Sequence-ID: 390 GET
Task-ID: 67439375
Query-Type: task-id
Content-Type: application/sdf; charset=utf-8
Content-Length: 655
workflow description
taskgroup description
If the SN does not understand the Task schema, it can discard the
description and send a 400 BAD REQUEST. Here, we will assume that the
receiver understands the request and can process it. After completing
the processing, the SN MUST send a 200 OK.
200 OK 1 SOP/1.0
From: default@4357254.provider.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@4357254.provider.com;branch=k9DjR5lbcw
Sequence-ID: 134 CREATE
The Proxy SHALL now commit the service. The COMMIT message is useful
when: (a) the workflow may involve many transactions in parallel, and
the Proxy may not commit requests if one of the transactions fails,
(b) the Proxy may have failed after making request, and the SN will
Dalela Expires July 4, 2012 [Page 17]
Internet-Draft SOP Message Flows January 2012
then cancel the earlier transaction and delete services. The Commit-
Timeout timer (received via the ADVERTISE) determines when
transactions must be cancelled.
COMMIT 1 SOP/1.0
From: default@p.provider.com
To: default@4357254.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=khewui6GDw
Sequence-ID: 134 COMMIT
Task-ID: 67439375
Workflow-Server: ws.provider.com
Requestor: consumer@customer.provider.com
On receiving the COMMIT the SN SHALL "activate" the service if the
service was dormant. The SN may use this occasion to perform clean up
tasks or other kinds of housekeeping. It will then send a 200 OK.
200 OK 1 SOP/1.0
From: default@4357254.provider.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@4357254.provider.com;branch=khewui6GDw
Sequence-ID: 134 COMMIT
The SN SHOULD send a PUBLISH indicating its new capabilities and
service availability. The capabilities may have reduced.
The Proxy MUST also COMMIT Workflow-ID in WS. This is a reference to
be used at the time of service deletion, and they will define how
create actions have to be reverted. Upon receiving a COMMIT, the WS
must create a Workflow description that the Proxy can send to the
Client. Note that not all the Tasks and their details need not be
made visible to the Client. However some of the actions must be. For
instance, if the use was allocating a VM, the address of the switch
to which the VM is attached should not be known, although the address
of the VM itself should be known. The WS has to return a Workflow
description that can be passed to the User. The WS SHOULD return this
reduced Task list to the Proxy as part of 200 OK.
200 OK 1 SOP/1.0
From: default@p.provider.com
To: consumer@customer.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.provider.com;branch=k9DjR5lbcw
Sequence-ID: 5 WORKFLOW
Workflow-Name: gTyuI82Zx@provider.com
Dalela Expires July 4, 2012 [Page 18]
Internet-Draft SOP Message Flows January 2012
Workflow-ID: 68743693
Content-Type: application/sdf; charset=utf-8
Content-Length: 655
workflow description
taskgroup description
The Proxy SHOULD forward the reduced Task list information to the
Client as part of the response to the original WORKFLOW request. This
information helps the Client deduce all information it needs to know
about the service, as well as what it needs to know to modify, delete
or transfer this service in future.
The Client MAY at any future time, obtain this information again
using a GET query on a specific Workflow-ID, Task-ID, etc. The Client
MAY also do a GET query on a Workflow-Name, with Query-Type set to
"active-workflows" and obtain all active Workflow-IDs against a
Workflow Name. The Workflow-IDs can then be used to query Task-IDs
and details of those Task and Workflow IDs. The WS that responds to
these queries must ensure that it is only sharing user-relevant
information and not information that the provider considers private.
6. Service Deletion
The service deletion works similar to service creation, except that
the initiating workflow is defined to be deleting a service instead
of creating. The deletion workflow request MUST mention the prior
Workflow-ID and/or Task-ID.
WORKFLOW 1 SOP/1.0
From: consumer@customer.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p.customer.com;branch=k9DjR5lbcw
Sequence-ID: 5 WORKFLOW
Workflow-Name: xhsdfpjTRm@provider.com
Dalela Expires July 4, 2012 [Page 19]
Internet-Draft SOP Message Flows January 2012
Workflow-ID: 68743693
The Proxy SHALL send a GET to the WS, asking for a workflow
description. The WS SHALL return a "flipped" workflow in the sense
that actions of provisioning have been reversed in deletion. The
order of tasks would be determined by the deletion workflow.
200 OK 1 SOP/1.0
From: default@ws.provider.com
To: default@p.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP ws@p.provider.com;branch=cw8gtrB56m
Sequence-ID: 286 GET
Workflow-Name: xhsdfpjTRm@provider.com
Workflow-ID: 68743693
Requestor: consumer@customer.com
Content-Type: application/sdf; charset=utf-8
Content-Length: 542
workflow description
taskgroup description
The WS SHALL allocate a new Workflow-ID and provide tasks that
reverse earlier service creation. The new Workflow-ID SHOULD have a
reference to the earlier Workflow-ID. Type of the task in the example
is set to "DELETE". The rest of the process remains unchanged as
compared to CREATE. COMMIT on the WS SHALL delete the original
Workflow-ID and Task-ID along with the new Workflow and Task IDs that
were created as part of the delete operation.
7. Service Update
The service update works similar to service creation, except that the
WORKFLOW request MUST reference prior Workflows and/or Tasks that are
being modified by the UPDATE. The service update workflow request
MUST mention the prior Workflow-ID and/or Task-ID. The WORKFLOW
Dalela Expires July 4, 2012 [Page 20]
Internet-Draft SOP Message Flows January 2012
request MAY also have a set of attributes being modified.
Alternately, the request MAY only invoke a workflow while the
attribute changes are determined by the WS.
WORKFLOW 1 SOP/1.0
From: consumer@customer.com
To: default@p.provider.com
Exchange: 437eYE3XY
Via: SOP/1.0/UDP default@p.customer.com;branch=k9DjR5lbcw
Sequence-ID: 5 WORKFLOW
Workflow-Name: xhsdfpjTRm@provider.com
Workflow-ID: 68743693
The Proxy SHALL send a GET to the WS, asking for a workflow
description. The WS SHALL return a "modified" workflow in the sense
that its Tasks include service updates, with references to prior
Tasks. The order of Tasks in the Workflow would be determined by the
update workflow.
200 OK 1 SOP/1.0
From: default@ws.provider.com
To: default@p.provider.com
Exchange: 437eYE3XY
Via: SOP/1.0/UDP ws@p.provider.com;branch=cw8gtrB56m
Sequence-ID: 286 GET
Workflow-Name: xhsdfpjTRm@provider.com
Workflow-ID: 68743693
Requestor: consumer@customer.com
Content-Type: application/sdf; charset=utf-8
Content-Length: 542
workflow description
taskgroup description
The WS SHALL allocate a new Workflow-ID and provide tasks that update
the earlier service creation. The new Workflow-ID SHOULD have a
Dalela Expires July 4, 2012 [Page 21]
Internet-Draft SOP Message Flows January 2012
reference to the earlier Workflow-ID. Type of the task in the example
is set to "DELETE". When this update is completed, the Proxy SHALL
commit the Tasks and Workflow. The COMMIT on the WS MAY delete the
modify Workflow-ID and Task-ID and update the original Workflow-ID.
8. Service Mobility
Two types of service mobility models are supported in SOP. These are
called the "stateful" and "stateless" models. In the "stateful"
model, live state of the service is transferred from one SN to
another. In the "stateless" model, the live state of the service is
not transferred. Rather, a new service instance is created and the
old one is then terminated. These two models are described below.
8.1. Stateful Service Mobility
In the "stateful" mobility model, live state of a service is
transferred from one SN to another. SOP does not cover the actual
state transfer of services (which may use existing protocols such as
FTP to copy a service state). SOP only sets up the necessary control
session, identifying resources, to transfer service states.
+----+ +--------+ +------+ +--------+ +--------+ +--------+
| WS | | Source | |Client| | Source | | Target | | Target |
| | | SN | | | | Proxy | | SN | | Proxy |
+----+ +--------+ +------+ +--------+ +--------+ +--------+
| | | | | |
| | | WORKFLOW | | |
| | |----------->| | |
| GET | | | | |
|<---------------------------------| | |
| 200 OK | | | | |
|--------------------------------->| | |
| | | |TRANSFER (src=SN1, dst=?)
| | | |----------------------->|
| | | | | TRANSFER |
| | | | (src=SN1, dst=SN2)
| | | | |<----------|
| | | | | 200 OK |
| | | | |---------->|
| | | 200 OK (src=SN1, dst=SN2)|
| | TRANSFER |<-----------------------|
| | (src=SN1, dst=SN2 ) | | |
| |<---------------------| | |
| | | | | |
| | service state transfer | |
| |<<<*****************************>>>| |
Dalela Expires July 4, 2012 [Page 22]
Internet-Draft SOP Message Flows January 2012
| | | | | |
| | 200 OK | | |
| |--------------------->| | |
| | COMMIT (terminate) | | |
| |<---------------------| | |
| | 200 OK | | |
| |--------------------->| COMMIT (activate) |
| COMMIT (workflow) |----------------------->|
|<---------------------------------| COMMIT (activate)|
| | | | |<----------|
| 200 OK (workflow) | | 200 OK |
|--------------------------------->| |---------->|
| | | | 200 OK |
| | | |<-----------------------|
| | PUBLISH | | PUBLISH |
| | (svc deleted) | | (svc created)
| |--------------------->| |---------->|
| | 200 OK | | 200 OK |
| |<---------------------| |<----------|
| | | 200 OK | | |
| | |<-----------| | |
Figure-5: Message Flow for Stateful Service Mobility
The Client initiates service mobility by sending the WORKFLOW
message. It MUST include references to past Workflows and/or Task-ID
that need to be moved. The Proxy that receives the WORKFLOW message
(called the Source Proxy) MUST forward the content of the WORKFLOW
message to the WS via a GET to obtain a description of the Workflow.
GET 1 SOP/1.0
From: default@p1.provider.com
To: default@ws.provider.com
Exchange: 43shXui7236
Via: SOP/1.0/UDP default@p1.provider.com;branch=k9oluElbcw
Sequence-ID: 286 WORKFLOW
Workflow-Name: gTyuI82Zx@provider.com
Query-Type: workflow-name
Requestor: consumer@customer.com
If the Workflow is authorized for the user and the WS can find the
appropriate resources to move the service, it SHALL send a 200 OK.
200 OK 1 SOP/1.0
From: service1@ws.provider.com
To: default@p1.provider.com
Exchange: 43shXui7236
Dalela Expires July 4, 2012 [Page 23]
Internet-Draft SOP Message Flows January 2012
Via: SOP/1.0/UDP default@4357254.provider.com;branch=cw8gtrB56m
Sequence-ID: 1 GET
Content-Type: application/sdf; charset=utf-8
Content-Length: 142
workflow description
taskgroup description
The source Proxy SHALL now begin executing the service transfer by
sending the TRANSFER message to the target Proxy. The target Proxy
SHOULD have been selected by the WS and populated as the "server" in
the element of the Task.
TRANSFER 1 SOP/1.0
From: default@p1.provider.com
To: default@p2.provider.com
Exchange: 4j253TyXuM6
Via: SOP/1.0/UDP default@p1.provider.com;branch=XsMf634d2W
Sequence-ID: 1 TRANSFER
Source: service1@4357254.provider.com
Transfer-Mode: service-mobility
Requestor: default@p1.provider.com
Content-Type: application/sdf; charset=utf-8
Content-Length: 142
Dalela Expires July 4, 2012 [Page 24]
Internet-Draft SOP Message Flows January 2012
The target Proxy SHOULD allocate a new home for the service based on
the received service description. After that, it will forward the
request to the selected SN to prepare it for receiving the service.
If the allocation fails, the target Proxy may reject the request.
TRANSFER 1 SOP/1.0
From: default@p2.provider.com
To: default@sn2.provider.com
Exchange: 4j253TyXuM6
Via: SOP/1.0/UDP default@p1.provider.com;branch=XsMf634d2W,
SOP/1.0/UDP default@p2.provider.com;branch=dfdsye50ZR
Sequence-ID: 1 TRANSFER
Source: service1@4357254.provider.com
Transfer-Mode: stateful
Requestor: default@p1.provider.com
Content-Type: application/sdf; charset=utf-8
Content-Length: 142
Note that the "Requestor" and "Source" headers are preserved to let
the receiving SN know the Proxy and Service being moved. If the
receiver SN approves of the move (it has the necessary domain
capabilities and the resources) it SHOULD send a 200 OK. The SN may
approve a modified service description from the one it received. The
SN must also add a "Destination" header as name of target service.
200 OK 1 SOP/1.0
From: default@sn2.provider.com
To: default@p2.provider.com
Exchange: 4j253TyXuM6
Via: SOP/1.0/UDP default@p2.provider.com;branch=dfdsye50ZR,
SOP/1.0/UDP default@p1.provider.com;branch=XsMf634d2W
Sequence-ID: 1 TRANSFER
Requestor: default@p1.provider.com
Source: service1@sn1.provider.com
Destination: service2@sn2.provider.com
Content-Type: application/sdf; charset=utf-8
Content-Length: 142
Dalela Expires July 4, 2012 [Page 25]
Internet-Draft SOP Message Flows January 2012
On receiving the 200 OK, the source Proxy MUST use the received
service description and send it in a TRANSFER message to the source
SN. If the source SN approves it, it SHOULD initiate service creation
using the Source and Destination headers as the From and To headers.
If the service transfer is successful, the source Proxy SHALL send
COMMIT messages to the source and target SNs.
COMMIT 1 SOP/1.0
From: default@p1.provider.com
To: service1@sn1.provider.com
Exchange: 4j253TyXuM6
Via: SOP/1.0/UDP default@p1.provider.com;branch=khewui6GDw
Sequence-ID: 13 COMMIT
Task-ID: 347654933
Source: service1@sn1.provider.com
Destination: service2@sn2.provider.com
COMMIT 1 SOP/1.0
From: default@p1.provider.com
To: service2@sn2.provider.com
Exchange: 4j253TyXuM6
Via: SOP/1.0/UDP default@p1.provider.com;branch=hfs634BDmn,
SOP/1.0/UDP default@p2.provider.com;branch=hprit5WCQv
Sequence-ID: 5 COMMIT
Task-ID: 4354395374
Source: service1@sn1.provider.com
Destination: service2@sn2.provider.com
The Source Proxy MUST also commit the Workflow in WS so that the new
location of the service is known at the WS. This location may be used
to determine subsequent mobility actions or service deletion.
8.2. Stateless Service Mobility
In stateless service mobility, a new service is created with
identical service meta-attributes, although the live state of the
current service instance is not copied to the new instance.
+----+ +--------+ +------+ +--------+ +--------+ +--------+
| WS | | Source | |Client| | Source | | Target | | Target |
| | | SN | | | | Proxy | | SN | | Proxy |
+----+ +--------+ +------+ +--------+ +--------+ +--------+
| | | | | |
| | | WORKFLOW | | |
| | |----------->| | |
| GET | | | | |
Dalela Expires July 4, 2012 [Page 26]
Internet-Draft SOP Message Flows January 2012
|<---------------------------------| | |
| 200 OK | | | | |
|--------------------------------->| | |
| | | | CREATE |
| | | |----------------------->|
| | | | | CREATE |
| | | | |<----------|
| | | | | 200 OK |
| | | | |---------->|
| | | | 200 OK | |
| | DELETE |<-----------------------|
| |<---------------------| | |
| | | | | |
| | 200 OK | | |
| |--------------------->| | |
| | COMMIT (terminate) | | |
| |<---------------------| | |
| | 200 OK | | |
| |--------------------->| COMMIT (activate) |
| COMMIT (workflow) |----------------------->|
|<---------------------------------| COMMIT (activate)|
| | | | |<----------|
| 200 OK (workflow) | | 200 OK |
|--------------------------------->| |---------->|
| | | | 200 OK |
| | |<-----------------------|
| | PUBLISH | | PUBLISH |
| | (svc deleted) | | (svc created)
| |--------------------->| |---------->|
| | 200 OK | | 200 OK |
| |<---------------------| |<----------|
| | | 200 OK | | |
| | |<-----------| | |
Figure-6: Message Flow for Stateless Service Mobility
This mobility model differs from the stateful mobility in that the
TRANSFER message is not used. Instead, the Workflow delivers two
independent but coordinated Tasks, one that creates a new service
instance and the other that deletes the old service instance.
This model of service mobility may be useful when the state of the
service resides outside the service (e.g. an external database). This
model may be used for disaster recovery, geographical redundancy, or
simply moving capacity dynamically from one site to another.
Dalela Expires July 4, 2012 [Page 27]
Internet-Draft SOP Message Flows January 2012
9. Security Considerations
Encryption and authentication of SOP messages is described in the
Service Orchestration Protocol document [SOP].
10. IANA Considerations
NA.
11. Conclusions
This document described message flows for a few important service
orchestration scenarios. These message flows are not exhaustive.
These can be extended to apply to multiple interoperability scenarios
as described in the SOP requirements document [REQT].
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[NIST] DRAFT Cloud Computing Synopsis and Recommendations
http://csrc.nist.gov/publications/drafts/800-146/Draft-
NIST-SP800-146.pdf
[REQT] Service Orchestration Protocol Requirements
http://www.ietf.org/id/draft-dalela-orchestration-00.txt
[ARCH] Service Orchestration Protocol Network Architecture
http://www.ietf.org/id/draft-dalela-sop-architecture-00.txt
[SOP] Service Orchestration Protocol
http://www.ietf.org/id/draft-dalela-sop-00.txt
[SDF] Service Description Framework
http://www.ietf.org/id/draft-dalela-sdf-00.txt
13. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Dalela Expires July 4, 2012 [Page 28]
Internet-Draft SOP Message Flows January 2012
Authors' Addresses
Ashish Dalela
Cisco Systems
Cessna Business Park
Bangalore
India 560037
Email: adalela@cisco.com
Mike Hammer
Reston
Virginia
USA 20190
Email: mphmmr@gmail.com
Monique Morrow
Cisco Systems [Switzerland] GmbH
Richistrasse 7
CH-8304
Walllisellen
Switzerland
Email: mmorrow@cisco.com
Peter Tomsu
Cisco Systems Austria GmbH
30 Floor, Millennium Tower
Handelskai 94-96
A-1200 Vienna
Austria
Email: ptomsu@cisco.com
Dalela Expires July 4, 2012 [Page 29]