[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn"/>


   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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn"/>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn"/>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn">
         <!-- list of domain attributes -->
     </domain>
     <domain name="iaas.compute" type="availability" def="sdn">
         <!-- list of domain attributes -->
     </domain>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn/>

   When a SUBSCRIBE is received, and the Proxy can support those
   domains, it MUST forward the SUBSCRIBE to an appropriate WS. The WS
   MUST validate if the user is authorized to receive those services. If
   the user is authorized, the WS SHALL respond with a 200 OK to the
   Proxy, and the Proxy SHALL forward the 200 OK to the Client.

     200 OK 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=k9DjR5lbcw
     Sequence-ID: 1 SUBSCRIBE

   After subscribing to certain domains the WS SHALL send updates on
   services through the PUBLISH message. These updates MUST be sent
   after the first SUBSCRIBE, whenever services availability changes
   (new services are available or old ones are removed), or upon expiry
   of a Publish-Timer, whichever comes first. The PUBLISH message SHOULD
   be forwarded to the Proxy which will send it to the Client. The Proxy
   MUST change the From header to its own address (to hide the WS from
   the Client). Upon receiving the PUBLISH, the Client SHOULD respond
   with a 200 OK confirming receipt.

   It SHOULD be possible to configure a WS for forwarding different
   categories of information to the User through a PUBLISH:

   -  A WS may forward details of every SN available in its network to
     the User and their individual service capabilities.


Dalela                   Expires July 4, 2012                  [Page 9]


Internet-Draft            SOP Message Flows                January 2012


   -  A WS may only forward aggregated status of SNs in the network,
     aggregated by domains, geographies, or other criteria.

   -  A WS may not forward any service status, but only mention that it
     supports services from a certain domain.

   -  A WS may send to the user a list of all Workflows available that
     may be of interest to the User.

   -  A WS may filter available Workflows and send only those Workflows
     that have been explicitly configured for the User.

   Accordingly, the PUBLISH can have different types of content. The
   receiving Proxy SHOULD use the Node-Type header to apply a node-
   specific policy of publishing (in conjunction with other policies).
   The example below shows a PUBLISH that publishes a Workflow.

     PUBLISH 1 SOP/1.0
     From: default@p.provider.com
     To: consumer@customer.com
     Exchange: 43shXui7236
     Via: SOP/1.0/UDP default@4357254.provider.com;branch=k9DjR5lbcw
     Sequence-ID: 13432 PUBLISH
     Distance: 1
     Content-Type: application/sdf; charset=utf-8
     Content-Length: 513

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="X32mnTrUwq" anchor="p.provider.com">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="2" action="CREATE">
            <domain name="iaas.compute" type="capability" def="sdn">
              <!-list of domain attributes -->
            </domain>
          </task>
          <task id="2" prev="1" next="idle" action="CREATE">
            <domain name="iaas.network" type="capability" def="sdn">
              <!-list of domain attributes -->
            </domain>
          </task>
       </taskgroup>
     </workflow>

   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 <workflow> 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

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="gTyuI82Zx" id="68743693"
         xmlns:sdf="http://sdf.org/sdf">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="idle" action="CREATE"
              server="4357254.provider.com reference="67439375"
              status="pending"/>
       </taskgroup>
     </workflow>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="gTyuI82Zx" id="68743693"
       xmlns:sdf="http://sdf.org/sdf">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="idle"
                server="4357254.provider.com ">
            <domain name="iaas.compute" def="sdn">
               <!-- list of domain attributes -->
            </domain>
        </task>
       </taskgroup>
     </workflow>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="gTyuI82Zx" id="68743693"
       xmlns:sdf="http://sdf.org/sdf">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="idle" action="CREATE">
            <domain name="iaas.compute" type="capability" def="sdn">
               <!-- list of domain attributes -->
            </domain>
        </task>
       </taskgroup>
     </workflow>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="xhsdfpjTRm" id="634794594"
          xmlns:sdf="http://sdf.org/sdf">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="idle" type="DELETE">
            <domain name="iaas.compute" alias="d1" def="sdn">
               <!-- list of domain attributes -->
            </domain>
          </task>
       </taskgroup>
     </workflow>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="xhsdfpjTRm" id="439356943"
          xmlns:sdf="http://sdf.org/sdf">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="idle" type="UPDATE">
            <domain name="iaas.compute" alias="d1" def="sdn">
               <!-- list of domain attributes -->
            </domain>
          </task>
       </taskgroup>
     </workflow>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <workflow name="xhsdfpjTRm" id="634794594">
       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="2" type="TRANSFER"
                    server="p2.provider.com" reference="347654933">
            <domain name="iaas.compute" alias="d1" def="sdn">
               <!-- list of domain attributes -->
            </domain>
          </task>
          <task id="2" prev="1" next="idle" type="TRANSFER"
                    server="p2.provider.com" reference="4354395374">
            <domain name="iaas.compute" alias="d1" def="sdn">
               <!-- list of domain attributes -->
            </domain>
          </task>
       </taskgroup>
     </workflow>

   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 <domain> 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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn">
         <!-- list of domain attributes -->
     </domain>



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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn">
         <!-- list of domain attributes -->
     </domain>

   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

     <?xml version="1.0" encoding="UTF-8"?>
     <domain name="iaas.compute" type="capability" def="sdn">
         <!-- list of domain attributes -->
     </domain>


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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/