Network Working Group A. Dalela Internet Draft Cisco Systems Intended status: Standards Track M. Hammer Expires: July 2012 January 4, 2012 Service Orchestration Protocol draft-dalela-sop-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 Service Orchestration Protocol January 2012 Abstract Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This document describes a Service Orchestration Protocol (SOP) to be used as a standard wire-format for cloud exchanges. Similar to widely used protocols like HTTP, SIP and SMTP, SOP uses text-based messages, which are easily extensible and may be inspected at cloud proxies. While SOP carries service-independent information, service-dependant information is attached as a Service Description Framework [SDF] payload to SOP packets. This is similar to how HTML is transported over HTTP. SDF is a XML schema for describing services. SOP and SDF enable any kind of service to be discovered and orchestrated across private and public domains. Simple protocol compliance tests can be employed to ensure interoperability across domains. SOP wire-formats can be used with existing cloud APIs. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. Table of Contents 1. Introduction...................................................5 2. Conventions used in this document..............................5 3. Terms and Acronyms.............................................5 4. Overview of Operation..........................................6 4.1. Service Discovery.........................................6 4.1.1. Proxy Discovery......................................6 4.1.2. Service, User and Proxy Registrations................7 4.1.3. Service Publishing and Subscribing...................8 4.1.4. Disambiguating Discovery Functions..................10 4.2. Service Management.......................................11 4.3. Service Reliability......................................12 4.4. Service Abstraction......................................13 5. Protocol Description..........................................14 5.1. Transport................................................15 5.2. Addressing...............................................15 5.3. Transactions and Exchanges...............................16 5.4. Service Accounting.......................................16 6. SOP Requests..................................................16 6.1. ADVERTISE................................................16 6.2. CANCEL...................................................17 6.3. COMMIT...................................................17 6.4. CREATE...................................................18 6.5. DELETE...................................................18 6.6. GET......................................................19 6.7. DISCOVER.................................................19 Dalela Expires July 4, 2012 [Page 2] Internet-Draft Service Orchestration Protocol January 2012 6.8. PUBLISH..................................................20 6.9. REGISTER.................................................20 6.10. SUBSCRIBE...............................................21 6.11. TRANSFER................................................21 6.12. UPDATE..................................................22 6.13. WORKFLOW................................................23 7. SOP Responses.................................................23 7.1. 100 TRYING...............................................23 7.2. 183 WORKFLOW PROGRESS....................................23 7.3. 200 OK...................................................24 7.4. 305 USE PROXY............................................24 7.5. 400 BAD REQUEST..........................................25 7.6. 403 FORBIDDEN............................................25 7.7. 500 SERVER INTERNAL ERROR................................25 7.8. 504 SERVER TIMEOUT.......................................26 7.9. 603 DECLINE..............................................26 8. SOP Headers...................................................26 8.1. Acknowledge Timeout......................................27 8.2. Alternate Proxy Header...................................27 8.3. Cancel Timeout Header....................................27 8.4. Commit Timeout Header....................................28 8.5. Content Type Header......................................28 8.6. Content Length Header....................................28 8.7. Distance Header..........................................28 8.8. Destination Header.......................................28 8.9. Exchange Header..........................................29 8.10. From Header.............................................29 8.11. Node Type Header........................................29 8.12. Priority Header.........................................29 8.13. Query Type Header.......................................29 8.14. Publish Timeout Header..................................30 8.15. Retry Count Header......................................30 8.16. Requestor Header........................................30 8.17. Registration Timeout Header.............................31 8.18. Service ID Header.......................................31 8.19. Sequence ID Header......................................31 8.20. Source Header...........................................31 8.21. Subscribe Timeout Header................................31 8.22. Task ID Header..........................................32 8.23. Timestamp Header........................................32 8.24. To Header...............................................32 8.25. Transfer Mode Header....................................32 8.26. Via Header..............................................32 8.27. Workflow ID Header......................................33 8.28. Workflow Name Header....................................33 8.29. Workflow Server Header..................................33 9. Timers and Counters...........................................33 Dalela Expires July 4, 2012 [Page 3] Internet-Draft Service Orchestration Protocol January 2012 9.1. Retransmission Counter...................................33 9.2. Acknowledge-Timeout......................................33 9.3. Register-Timeout.........................................34 9.4. Advertise-Timeout........................................34 9.5. Cancel-Timeout...........................................34 9.6. Commit-Timeout...........................................34 9.7. Discover-Timeout.........................................34 9.8. Publish-Timeout..........................................35 9.9. Subscribe-Timeout........................................35 9.10. Retransmit-Timeout......................................35 10. Message-Header Relationships.................................35 11. Security Considerations......................................36 12. IANA Considerations..........................................37 13. Conclusions..................................................37 14. References...................................................37 14.1. Normative References....................................37 14.2. Informative References..................................37 15. Acknowledgments..............................................37 Dalela Expires July 4, 2012 [Page 4] Internet-Draft Service Orchestration Protocol January 2012 1. Introduction This document describes a protocol for discovering, publishing and orchestrating services in the Internet. A detailed requirement set for such a protocol is described separately [REQT]. The present protocol scheme comprises of two protocols - the Service Orchestration Protocol (SOP) and a Service Description Framework (SDF). SOP carries service-independent information while SDF encodes service-dependant information. The relation between SOP and SDF is similar to that between SIP and SDP or between HTTP and HTML. This document describes SOP. SDF is described separately [SDF]. SDF payloads can be attached in SOP messages, and this document illustrates that. Through separation of service-independent and service-dependant pieces, the scheme described here can be extended to any service type in an interoperable way. SOP uses text-based headers similar to HTTP, SIP and SMTP. This makes SOP very easy to implement. To extend SOP, one only needs to add new text headers, or occasionally new methods. These messages may be inspected at cloud Proxies and modified by them. 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) 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 Attributes (VSA) in this document have the same meaning as define the SDF specification [SDF]. Dalela Expires July 4, 2012 [Page 5] Internet-Draft Service Orchestration Protocol January 2012 4. Overview of Operation 4.1. Service Discovery Before Users can orchestrate services, SNs, Proxies and Users must discover each other, and their service-related capabilities. If the number of users, SNs and Proxies is small, this discovery is achieved by configuring addresses manually. But, in a large network with a variety of services, automated discovery procedures are needed. This section describes SOP automated discovery procedures in three steps: (a) discovery of the Proxy, (b) registration to the Proxy and Identity validation, and (c) exchanging service information via the Proxy through service subscription and publishing. 4.1.1. Proxy Discovery A Proxy orchestrates services on a SN. To do this orchestration, the Proxy needs to discover SNs. A simple approach to discovery is that we can configure the SN with the Proxy or the Proxy with the SN address. The Proxy can then query the SN to know if it exists or the SN can heartbeat with the Proxy to announce its presence. This configuration is very cumbersome and error prone at scale and not a preferred method of service discovery. A more appropriate approach is that we use SOP messages for dynamic discovery. A Proxy needs to advertize its presence along with the ability to proxy for certain services. A SN can discover service- specific Proxies by listening to Proxy advertisements. A SN should also be able to trigger service discovery because the SN may have been out of service when the Proxy advertized its presence. Two messages are used in SOP - ADVERTISE and DISCOVER - to support proxy discovery. The Proxy sends ADVERTISE to announce its presence and ability to handle some services. The SN uses DISCOVER to trigger the ADVERTISE, if an ADVERTISE has not been transmitted or if it was transmitted but the SN was not operational to receive it. These two messages are independent requests, and not related as request-response. A Proxy SHALL periodically send an ADVERTISE to announce its presence. A SN SHALL send a DISCOVER whenever it starts up and if an ADVERTISE has not already been received. A Proxy SHOULD send a ADVERTISE in response to a DISCOVER if the service types in the DISCOVER match with the service types supported by the Proxy. The DISCOVER SHOULD be always broadcast. The ADVERTISE may be unicast or broadcast. Periodically sent ADVERTISE messages SHOULD be Dalela Expires July 4, 2012 [Page 6] Internet-Draft Service Orchestration Protocol January 2012 broadcast. ADVERTISE sent in response to DISCOVER SHOULD be unicast (the unicast address is derived from the received DISCOVER). +--------+ +--------+ | Proxy | | SN | +--------+ +--------+ | DISCOVER | |<---(I need Proxy for XYZ svcs.)---| | | | ADVERTISE | |---(I can Proxy for XYZ svcs.)---->| | | 4.1.2. Service, User and Proxy Registrations After receiving the ADVERTISE message from a Proxy, and if the service interests match, a SN, a WS, User or Proxy SHOULD register with the Proxy. If a SN supports multiple services, it SHOULD register with those Proxies that support those services. If a Client is interested in services supported by multiple Proxies, it SHOULD register with all of them. If a Proxy is interested in exchanging service information with multiple Proxies, it should register with them. Registration identifies the SN, WS, User or Proxy to the registering Proxy. +------------------+ +--------+ | SN/WS/User/Proxy | | Proxy | +------------------+ +--------+ | | | REGISTER | |-----(Here is my Identity)---->| | | |<---------- 200 OK ------------| | | The Proxy receiving registration MAY initiate authentication during the registration. The Proxy SHOULD interact with a AAA server to authenticate and/or challenge the registration identity. Registrations MUST be carried out periodically, and they act as a keep-alive mechanism with the Proxy. A registration MAY be used to determine the location of a User, Proxy, WS or SN, and location based policies can be applied in service orchestration. Dalela Expires July 4, 2012 [Page 7] Internet-Draft Service Orchestration Protocol January 2012 4.1.3. Service Publishing and Subscribing There are two kinds of service publishing. First, the SN publishes its capabilities to the Proxy. Second, the Proxy publishes the aggregate of SN capabilities to other Proxies and Users. These publications build up the service routing tables in network and Users and Proxies can know how to route a request to a service. Service publishing uses the PUBLISH message. This message uses request-response, and a response SHOULD be sent by the receiver. A SN SHOULD send PUBLISH because of service virtualization. Each SN may be capable of hosting multiple virtualized service instances. As those instances are allocated, the total virtualized capacity in the SN reduces. The SN needs to inform the Proxy about its current capacity to host services. A Proxy WOULD aggregate these capacities and can use them to determine the placement of services. A SN SHOULD send a PUBLISH to a Proxy in the following three cases, whichever comes first: a. Periodically based on a time indicated by the Proxy (in the ADVERTISE message). A Proxy SHOULD null the SN's capabilities if 3 successive PUBLISH messages have not been received. b. When the SN is started, to inform about its available capacity. c. Whenever its service capabilities change; this may be typically after a new service allocation or partial failure/outage. A Proxy SHOULD also send PUBLISH to other Proxies and Users to propagate service capabilities in the network. As new services are made available, or existing ones are removed, Users need to know the available list of services. A Proxy can dynamically publish its catalogue of discovered services to the user. These publications can carry two kinds of information. First, they can have an aggregated view of service capabilities available via a Proxy. This information is useful to a receiver to determine which services can be accessed via a publisher. Second, the PUBLISH can indicate the Workflows that can be requested through a Proxy. The Workflows will be tagged by service types, so a user can know which Workflows will result in which kinds of services. In certain cases publishing an aggregated view of services may be undesirable at it exposes a provider's internal details to other providers or users. The PUBLISH may however carry aggregated services Dalela Expires July 4, 2012 [Page 8] Internet-Draft Service Orchestration Protocol January 2012 to a limited set of trusted Proxies. It SHOULD always carry Workflows to all Users or Proxies that may need to use the Workflows. +----+ +-------+ | SN | | Proxy | +----+ +-------+ | PUBLISH | |-------(Update on svc X)------>| | | |<---------- 200 OK ------------| | | +----+ +-------+ | WS | | Proxy | +----+ +-------+ | PUBLISH | |---(List of Avlbl Workflows)-->| | | |<---------- 200 OK ------------| | | +-------+ +-------+ | Proxy | | Proxy | +-------+ +-------+ | PUBLISH | |---(List of Avlbl Workflows--->| | and Aggregate Services) | | | |<---------- 200 OK ------------| | | +-------+ +-------+ | Proxy | | Client| +-------+ +-------+ | PUBLISH | |---(List of Avlbl Workflows)-->| | | |<---------- 200 OK ------------| | | Of course, not every Proxy or User may be interested in every kind of service. As the service catalogue grows, the total amount of publishing can be an overhead as no User will be interested in all services and a Proxy or User may be interested in only a subset of these services. To avoid flooding, a User or Proxy can indicate its service interests by sending a SUBSCRIBE to the Proxy. The SUBSCRIBE Dalela Expires July 4, 2012 [Page 9] Internet-Draft Service Orchestration Protocol January 2012 SHALL indicate the sender's service interests, which act as a filter for a Proxy to forward only those service-specific details. +--------+ +-------+ | Client | | Proxy | +--------+ +-------+ | SUBSCRIBE | |-----(Interested Svc List)---->| | | |<---------- 200 OK ------------| | | +-------+ +-------+ | Proxy | | Proxy | +-------+ +-------+ | SUBSCRIBE | |-----(Interested Svc List)---->| | | |<---------- 200 OK ------------| | | A Proxy MAY use information gleaned during registration to determine which Users and Proxies should be forwarded which information. For instance, it might forward aggregated service information to Proxies within a trust zone, but send only Workflows to external Users. 4.1.4. Disambiguating Discovery Functions There are similarities in DISCOVER/ADVERTISE and PUBLISH/SUBSCRIBE mechanisms. A SN indicates its service class to the Proxy via DISCOVER and the Proxy advertizes its service class to SN via ADVERTISE. Similarly, a User indicates its service interest via SUBSCRIBE to the Proxy. The Proxy indicates its service capabilities with the PUBLISH to the User. This similarity leads to the question of why we need separate messages for these two functions. The reason for separating DISCOVER/ADVERTISE from PUBLISH/SUBSCRIBE is that the ADVERTISE/DISCOVER messages may be broadcast and there are no responses to them whereas the PUBLISH/SUBSCRIBE messages are always unicast and every message has a response. It is simpler to keep these messages and preserve their broadcast/unicast and request- only versus request-response behaviors than combining them. There is similarity in REGISTER/PUBLISH and REGISTER/SUBSCRIBE messages (these messages are unicast and follow the request-response pattern). Both REGISTER and PUBLISH indicate a SN's information to Dalela Expires July 4, 2012 [Page 10] Internet-Draft Service Orchestration Protocol January 2012 the Proxy. The difference between them is that a REGISTER informs a Proxy about the SN's identity (Domain Name and IP Address) whereas a PUBLISH informs the Proxy about its Service Domain Name (SDN) and capabilities. Similarly, a REGISTER informs a Proxy about the User's Identity (Domain Name and IP Address) whereas a SUBSCRIBE informs the Proxy about the User's SDN interests. So, we have a 3-way distinction between Capability and Interest which are described in SDN and Identity which is in terms of DNS and IP. The reason to keep the REGISTER separate from PUBLISH/SUBSCRIBE is to separate Identity (DNS and IP) from Service (SDN). Identity requires authentication, and if a User or SN have been authenticated, this Identity should be usable across all service requests. Authentication should not be required in every service transaction. By confining Identity validation to REGISTER, other requests can use that Identity and don't have to authenticate the User or SN separately. We can think of REGISTER as a single sign-on used for services. 4.2. Service Management Service management comprises of five main functions: CREATE, DELETE, UPDATE, GET and TRANSFER. The first four messages have a close parallel to the CRUD methods defined in HTTP as shown below. +-------------------+-------------------+-------------------+ | SOP Message | CRUD Method | HTTP Message | +-------------------+-------------------+-------------------+ | CREATE | CREATE | POST | | GET | READ | GET | | UPDATE | UPDATE | PUT | | DELETE | DELETE | DELETE | | TRANSFER | - | - | +-------------------+-------------------+-------------------+ +--------+ +--------+ | Proxy | | SN | +--------+ +--------+ | CREATE | |----(Services of Domain X)---->| | | |<---------- 200 OK ------------| | | The CREATE, DELETE and UPDATE messages have obvious semantics in relation to services. The GET message requests a description of the service or workflow or tasks depending on the context. This GET is Dalela Expires July 4, 2012 [Page 11] Internet-Draft Service Orchestration Protocol January 2012 not related to the service but to its meta-attributes used in orchestration. For instance, the GET will fetch the total allocated size of a storage disk but not the content of that disk. The TRANSFER message is unique to SOP, and arises because of service virtualization and movement of services. The TRANSFER message sets up the context in which service information may be transferred from one point to another, such as the source and destination addresses and the type of information to be transferred. It does not deal with the actual transfer of information. The latter kind of transfer may be determined by the service itself (such as use of SFTP to transfer memory snapshots in case of VM mobility). +--------+ +--------+ | Source | | Target | | Proxy | | Proxy | +--------+ +--------+ | TRANSFER | |-------(src=SN1, dst=?)------->| | | | 200 OK | |<-----(src=SN1, dst=SN2)-------| | | 4.3. Service Reliability Service orchestration requires reliability that spans multiple SNs. A typical usable service may require orchestration across compute, network, storage, security, etc. Orchestration failure in one of these SNs should trigger a rollback of actions in all other SNs. This is achieved by sending the CANCEL message to the SNs that are impacted by a failure. If however all SNs have been orchestrated successfully, then a COMMIT message is sent to all the SNs. +--------+ +--------+ | Proxy | | SN | +--------+ +--------+ | COMMIT | |----(Services of Domain X)---->| | | |<---------- 200 OK ------------| | | Every service transaction in SOP must be committed within a certain time period. If the time for commit has elapsed, the service will be automatically rolled back by the SN. This mechanism is essential to Dalela Expires July 4, 2012 [Page 12] Internet-Draft Service Orchestration Protocol January 2012 handle scenarios where the User, the Proxy, some SNs or a combination of these fail. If the Proxy has failed and does not send the COMMIT to a SN, the SN SHALL rollback the transaction. If the SN has failed and does not respond to the Proxy, the Proxy SHALL send a CANCEL to other Proxies and/or SNs. If Proxy has failed and does not respond to the User, the User can be assured that they are not billed for the service. The provider can be assured that unless a COMMIT has been sent, service resources will not be leaking due to failures. 4.4. Service Abstraction For complex Workflows, there is need for a Workflow Anchor [ARCH]. Each Workflow may have a different Anchor. The Anchor controls the Workflow execution, and is responsible for validating the Workflow prior to execution. A Workflow MUST NOT be branched into Tasks by any network element upstream from the Anchor. The Proxy that advertizes the Workflow into the service network SHALL indicate through the PUBLISH messages that it is the Anchor of the Workflow. This allows a request to be routed to the correct Proxy (Anchor) for execution. Since a Workflow cannot be branched prior to the Workflow Anchor, all network elements upstream from the Anchor must request the Workflow as an atomic element. The WORKFLOW message is used to make this atomic request. This message MUST contain the Workflow Name being requested. The request MAY also contain a complete or partial Workflow description. All network elements prior to the Anchor MUST forward the WORKFLOW request without branching it into Tasks. On the receiving the WORKFLOW message, the Anchor SHALL extract the Workflow and send it to the relevant WS along with the Workflow Name through the GET message, requesting the WS to validate and complete the Workflow specification. The Workflow in the GET request represents the input to the WS to construct a complete Workflow specification. The WS may override the Workflow description, or may reject the GET request, depending on configured policies. +--------+ +-------+ | Proxy | | Proxy | +--------+ +-------+ | WORKFLOW | |--------(Workflow Name)------->| | | |<---------- 200 OK ------------| | | If the Workflow has been accepted, the complete Workflow specification SHALL specify individual Tasks as CREATE, DELETE, Dalela Expires July 4, 2012 [Page 13] Internet-Draft Service Orchestration Protocol January 2012 TRANSFER, COMMIT, etc. that the Anchor can execute. On receiving the completed Workflow specification, the Anchor SHALL proceed to executing the Workflow. If the Workflow has been rejected, the Anchor SHALL forward the reject to the upstream network element. The WORKFLOW message allows service bundles to be treated as atomic services for upstream network elements. A customer or provider can create a Workflow description and PUBLISH it through the service network using a unique service name. Users or Providers can request this service through the WORKFLOW message. By anchoring the Workflow in a particular location, the correct execution of the Workflow can be guaranteed. The Anchor ensures that the Workflow is validated and authorized prior to execution and accounted after completion. 5. Protocol Description SOP is a text-based protocol used for discovering, requesting, updating, moving and tearing down services. The protocol has a number of similarities with SIP, HTTP and SMTP: - SOP uses text-based headers - SOP separates control and data, as in SIP/SDP, HTTP/HTML - Uses 1xx-6xx responses o 1xx Informational Responses o 2xx Successful Responses o 3xx Redirection Responses o 4xx Client Failure Responses o 5xx Server Failure Responses o 6xx Global Failure Responses - Defines unique request types o DISCOVER :: Used by a SN to discover a Proxy o ADVERTISE :: Used by a Proxy to Advertize its Presence o REGISTER :: Used by a SN to register itself with a Proxy o PUBLISH :: Used by a SN to indicate its Capabilities o SUBSCRIBE :: Used by a WS/Client to subscribe to service info o CREATE :: Used by a Proxy to request service creation o DELETE :: Used by a Proxy to request service deletion o UPDATE :: Used by a Proxy to request service update o GET :: Used by a Proxy/SN to get service/workflow details o TRANSFER :: Used by a Proxy to request service mobility o COMMIT :: Used by a Proxy to commit service changes o CANCEL :: Used by a Proxy/Client to cancel operations o WORKFLOW :: Used by a Proxy/Client to execute a workflow Dalela Expires July 4, 2012 [Page 14] Internet-Draft Service Orchestration Protocol January 2012 5.1. Transport SOP implementations can use UDP or TCP transports. Service orchestration creates, deletes, configures and moves services. These transactions need to be highly reliable and scalable. The combination of reliability and scalability is hard to achieve at the transport layer. If a proxy manages millions of services, persistent TCP connections don't scale. If millions of users connect to a Proxy to obtain services, transporting them over UDP can be error prone. Keeping in mind these constraints, it is ideal to use TCP for short- lived user interactions and UDP for long-lived service management interactions. SOP has built in timers to COMMIT / CANCEL procedures to deal with network reliability issues in case the Proxy fails or the connection to the Proxy fails. As such, SOP will work correctly with use of either TCP or UDP. The choice of transport therefore depends on the desired scale and reliability of deployment. Limitations of transport may also be overcome through additional means. For instance it is possible to deploy a set of TCP Proxies that offloads TCP scale outside the SOP Proxy. Alternately we can use UDP transport in combination with shorter retransmit timers and increased retransmit counters. SOP has procedures to dynamically distribute timer and counter values across the network. 5.2. Addressing All entities in SOP are addressed by a user@domain name. The user "default" can be used in the following circumstances: - For addressing Proxies and WSs - For addressing a service when it does not have a name assigned (this can happen prior to SN registration) - For addressing entities in a broadcast message - If a sender does not know which user to address it to Outside of above cases, SNs SHOULD be addressed by a name such as service@sn.provider.com, where "sn" is a service node and "service" is a virtual service instance at the SN. If there is one SN for many virtualized service instances, the SN WOULD receive all messages for virtualized service instances, even though they are addressed to a particular "service". The SN MAY take actions on a request on behalf of the service or pass on information to the service. When messages are being broadcast, an address of the type default@default.provider.com may be used, and the packet will use a broadcast IP address. Dalela Expires July 4, 2012 [Page 15] Internet-Draft Service Orchestration Protocol January 2012 5.3. Transactions and Exchanges A "transaction" identifies as pair-wise message transfer between SOP network entities. Transactions correlate requests with responses. The "branch" parameter in the Via header identifies a transaction between two SOP network entities. The branch parameter is added by the request initiator to identify a new request and MUST be included by the responding entity in its response messages. A service request may branch out into multiple SOP network nodes, such as to allocate different resources (compute, network, storage and security) through the same request. The requests and responses are part of the same "exchange". The Exchange identifies a set of transactions that must be executed to complete a single service request. The combination of a "branch" and "exchange" uniquely identifies a message in the service network. 5.4. Service Accounting Accounting responsibilities rest with the Proxy. The Proxy SHALL start service accounting by sending an Accounting Start request to the AAA server. It SHALL stop service accounting by sending an Accounting Stop request to the AAA server. These messages (or enhancements to these messages for supporting service specific accounting functions) are outside scope of current document. 6. SOP Requests Every SOP request MUST have the Message Type, From and To headers. Messages with request-response MUST have the Exchange and Via headers. Messages without request-response (ADVERTISE and DISCOVER) MAY NOT have Exchange and Via headers. Other headers vary from message to message as described below. The meanings of all headers are described in Section 8. 6.1. ADVERTISE This message SHALL be sent by a Proxy to advertize its presence and willingness to proxy for certain types of services. The SDF payload in the message indicates which service domains it can support. In the example message below, the Proxy supports the iaas.compute domain of services. The message SHOULD carry the Registration-Timeout header. The message may also carry other Timer values and Retry counts as a way to globally configure all SNs in the network uniformly. ADVERTISE 1 SOP/1.0 Dalela Expires July 4, 2012 [Page 16] Internet-Draft Service Orchestration Protocol January 2012 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 Content-Type: application/sdf; charset=utf-8 Content-Length: 147 6.2. CANCEL This message is used to cancel a transaction that has not been committed in case of errors detected or in case of a timeout. The cancellation is a new transaction and it requires a response. The CANCEL refers to the Task to be cancelled through the Task-ID header. The receiver of the request MAY obtain a description of the Task again by querying the WS with the Task-ID provided in the message. CANCEL 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 CANCEL Task-ID: 67439375 Workflow-Server: ws.provider.com Requestor: consumer@customer.provider.com 6.3. COMMIT This message MUST be used to commit CREATE, DELETE, UPDATE or TRANSFER transactions. This message SHOULD be sent by the Proxy to each SN involved in a Workflow after all Tasks have been successfully completed. However, the Workflow specification may override this through a specification of when the COMMIT should be sent. The COMMIT refers to the Task to be committed through the Task-ID header. The receiver of the request MAY obtain a description of the Task again by querying the WS with the Task-ID provided in the message. The Proxy SHOULD also send a COMMIT to the WS to commit the Workflow. This is an indication to the WS that the Workflow execution was successful. The WS upon receipt of a COMMIT SHALL store the Workflow instance for reference later, and return a Workflow-ID. This Dalela Expires July 4, 2012 [Page 17] Internet-Draft Service Orchestration Protocol January 2012 Workflow-ID SHOULD be used to recreate services (in case of disaster recovery) or reverse them (in case of service deletion). 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 6.4. CREATE This message SHOULD be used by a Proxy to request a service creation to a SN. The CREATE refers to the Task to be executed through the Task-ID header. The receiver of the request SHOULD obtain a Task description by querying the WS with the Task-ID provided in message. 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 6.5. DELETE This message SHOULD be used by a Proxy to request a service deletion to a SN. The DELETE refers to the Task to be executed through the Task-ID header. The receiver of the request SHOULD obtain a Task description by querying the WS with the Task-ID provided in message. DELETE 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 DELETE Task-ID: 67439375 Workflow-Server: ws.provider.com Requestor: consumer@customer.provider.com Dalela Expires July 4, 2012 [Page 18] Internet-Draft Service Orchestration Protocol January 2012 6.6. GET This message MUST be used by a SN to obtain a Task description from a WS. It SHOULD be used by a Proxy to request a SN description prior to a service transfer. It MUST be used by a Proxy to obtain a Workflow or Task description from a WS. The context of the Transaction determines which of these functions need to be achieved. Depending on the context, appropriate headers must be present. To request a SN description, a Proxy MUST include the Service-ID header to point to refer to the specific service whose description is required. To get a workflow or task description, the appropriate Workflow-Name, Workflow-ID or Task-ID headers MUST be present. The Query-Type header MUST be present to describe the type of query. 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 Query-Type: workflow-name Workflow-Name: gTyuI82Zx@provider.com 6.7. DISCOVER This message SHOULD be sent by a SN to discover any Proxies that might be willing or capable to act as Proxy for its services. The SDF content in the message indicates service capabilities in the SN. In the example below, the SN is capable of iaas.compute domain of services. DISCOVER 1 SOP/1.0 From: default@default.com 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: 147 Dalela Expires July 4, 2012 [Page 19] Internet-Draft Service Orchestration Protocol January 2012 6.8. PUBLISH This message SHOULD be sent by a SN whenever its service capabilities change or when the Publish-Timeout timer expires or after a service restart (after a registration), whichever comes earlier. This message indicates the current service availability of the SN to the Proxy. The Proxy will use the information given in the SDF payload to update its service database. The capabilities indicated here would be used by the Proxy to route service requests towards the SN. The "capability" and "availability" inside the SDF indicate the total capacity and the capacity that is available currently. PUBLISH 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 Content-Type: application/sdf; charset=utf-8 Content-Length: 513 6.9. REGISTER This message SHOULD be used by a SN, a Proxy, a WS or a User to register with a Proxy after a new Proxy discovery, or when the Registration-Timeout expires, whichever comes earlier. The Node-Type header informs the Proxy about the type of registering entity. If the Node-Type header indicates a service-node, then the message MAY have the Transfer-Node header, indicating type of mobility the SN supports. For other node-types, Transfer-Node header MUST be absent. The REGISTER is used by the Proxy to establish the Identity of the SN (its Domain Name and IP Address). The Proxy MAY initiate authentication procedures with the registering entity after the REGISTER is received as described in Section. If the registration fails, the Proxy SHALL NOT register the entity. Dalela Expires July 4, 2012 [Page 20] Internet-Draft Service Orchestration Protocol January 2012 The REGISTER is used by the Proxy as a heartbeat or keep-alive mechanism. The Proxy SHALL de-register the entity if 3 successive Registration-Timeouts have expired, and remove all information related to that service. The Proxy MAY initiate service recreation procedures for all services under that SN at another SN, if a SN has been de-registered due to Registration-Timer expiry. 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: stateless Node-Type: service-node 6.10. SUBSCRIBE This message allows a SOP network element to request updates on a particular type of service capability. The SDF payload MUST be present to know the capabilities for which the requestor is subscribing. A WS SHALL subscribe with the Proxy for all updates to services and all updates to user registrations. A User MAY subscribe with the Proxy to receive Workflow and service related updates. SUBSCRIBE 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 Distance: 1 Content-Type: application/sdf; charset=utf-8 Content-Length: 154 6.11. TRANSFER This message is sent by a Proxy to initiate a service transfer. The From and To headers SHALL indicate the source and destination Proxies. The Source and Destination headers MUST be present and they indicate the source and destination SNs. The Requestor header MUST be present to identify the initiator of the transfer (this may be a Dalela Expires July 4, 2012 [Page 21] Internet-Draft Service Orchestration Protocol January 2012 Proxy). The TRANSFER message sets up the session to initiate a service transfer. It is not responsible for actually transferring service state from one SN to another. The latter is outside the scope of the current document, and each service may choose its own methods to transfer state (such as FTP to transfer a file). The SDF payload in the TRANSFER message SHALL indicate to the Destination SN the capabilities expected in the transfer. For instance, these capabilities may indicate the total amount of memory or storage required to accept a moving virtual machine. The content of that memory is outside scope for SOP and to be handled separately. TRANSFER 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 Requestor: default@p1.provider.com Content-Type: application/sdf; charset=utf-8 Content-Length: 142 6.12. UPDATE This message SHOULD be used by a Proxy to request a service update to a SN. The UPDATE refers to the Task to be executed through the Task- ID header. The receiver of the request SHOULD obtain a description of the Task by querying the WS with the Task-ID provided in the message. UPDATE 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 Dalela Expires July 4, 2012 [Page 22] Internet-Draft Service Orchestration Protocol January 2012 6.13. WORKFLOW This message is used by a Client or a Proxy to initiate a Workflow execution. It MUST contain the Workflow-Name that needs to be executed. It MUST contain a reference to the prior Workflow-ID when the request involves deletion or transfer of a prior executed Workflow. 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 7. SOP Responses 7.1. 100 TRYING This message MUST be sent by a Proxy on receiving a Workflow request. It indicates that the Proxy has received the request and is attempting to execute it. This message SHOULD be sent by a receiving SN upon a CREATE, UPDATE, DELETE or TRANSFER request, as these operations can take a longer period of time. This message informs the Proxy that the request has been received and it being processed. 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: 1 TRYING Workflow-Name: gTyuI82Zx@provider.com 7.2. 183 WORKFLOW PROGRESS The Proxy may send these messages periodically to the Client keeping it informed about the update. These message MAY have a Workflow description that describe the progress in execution. 183 SESSION PROGRESS 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: 1 TRYING Dalela Expires July 4, 2012 [Page 23] Internet-Draft Service Orchestration Protocol January 2012 Workflow-Name: gTyuI82Zx@provider.com Content-Type: application/sdf; charset=utf-8 Content-Length: 542 workflow description taskgroup description 7.3. 200 OK This message is sent by multiple entities including the WS, Proxy and SNs to indicate successful completion of the requests. Depending on the context, message contents and headers will vary. Below is an example message sent by the Proxy on completion of a CREATE. 200 OK 1 SOP/1.0 From: default@4357254.provider.com To: default@p.provider.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@sn.provider.com;branch=k9DjR5lbcw Sequence-ID: 134 CREATE Task-ID: 67439375 Workflow-Server: ws.provider.com 7.4. 305 USE PROXY This message is sent by a Proxy if it wants to redirect the requestor to another Proxy and will not service the request itself. The message MUST have the Alternate-Proxy header. 305 USE PROXY 1 SOP/1.0 From: default@p.provider.com To: user@customer.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@p1.provider.com;branch=k9DjR5lbcw Sequence-ID: 1 WORKFLOW Alternate-Proxy: default@p2.provider.com Workflow-Name: gTyuI82Zx@provider.com Dalela Expires July 4, 2012 [Page 24] Internet-Draft Service Orchestration Protocol January 2012 7.5. 400 BAD REQUEST This message SHALL be sent by a Proxy or a WS or a SN if they find the request malformed. Below is an example message. 400 BAD REQUEST 1 SOP/1.0 From: default@p.provider.com To: user@customer.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@p1.provider.com;branch=k9DjR5lbcw Sequence-ID: 1 WORKFLOW Workflow-Name: gTyuI82Zx@provider.com 7.6. 403 FORBIDDEN This message SHALL be sent by a Proxy or a WS if they find the user is not authorized to perform an operation. This may be used by a Proxy to indicate that it needs to authenticate in a REGISTER. The message may be used if a Proxy or WS finds that a user is not authorized to execute a Workflow. 403 FORBIDDEN 1 SOP/1.0 From: default@p.provider.com To: user@customer.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@p1.provider.com;branch=k9DjR5lbcw Sequence-ID: 1 WORKFLOW Workflow-Name: gTyuI82Zx@provider.com 7.7. 500 SERVER INTERNAL ERROR This message SHALL be sent by a Proxy or a WS or a SN if they tried to process a request but failed to some internal error. A SN will typically send this request if it fails to perform requested operation (like service creation, deletion, update, etc.). 500 SERVER INTERNAL ERROR 1 SOP/1.0 From: default@p.provider.com To: user@customer.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@p1.provider.com;branch=k9DjR5lbcw Sequence-ID: 1 WORKFLOW Workflow-Name: gTyuI82Zx@provider.com Dalela Expires July 4, 2012 [Page 25] Internet-Draft Service Orchestration Protocol January 2012 7.8. 504 SERVER TIMEOUT This message SHALL be sent by a Proxy if one of the SNs fails to respond to a request, and the Proxy times out on retransmits. 504 SERVER TIMEOUT 1 SOP/1.0 From: default@p.provider.com To: user@customer.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@p1.provider.com;branch=k9DjR5lbcw Sequence-ID: 1 WORKFLOW Workflow-Name: gTyuI82Zx@provider.com 7.9. 603 DECLINE This message SHALL be sent by a Proxy, WS or SN if it is not able to support the request, because there is no capacity available. This response SHOULD be sent if the Proxy knows that no other Proxy will be able to support this request (otherwise send 305 USE PROXY). The scope of the DECLINE is the set of Proxies that this Proxy knows of. 603 DECLINE 1 SOP/1.0 From: default@p.provider.com To: user@customer.com Exchange: 43shXui7236 Via: SOP/1.0/UDP default@p1.provider.com;branch=k9DjR5lbcw Sequence-ID: 1 WORKFLOW Workflow-Name: gTyuI82Zx@provider.com 8. SOP Headers SOP messages comprise of headers. Each header begins on a new line. Each header field consists of a field name followed by a colon (":") and the field value. field-name:field-value Header fields follow the same generic header format as that given in Section 7.3.1 of RFC 3261. The order of fields is not important in a SOP message however it is recommended that fields relevant to service routing (To, From, Exchange, Via) are present at the top of the message to facilitate rapid processing. The first line of every SOP message must have the name of the request or response, along with the SOP version number. This message name determines the subsequent processing of messages. Example message name headers are shown below. Dalela Expires July 4, 2012 [Page 26] Internet-Draft Service Orchestration Protocol January 2012 CREATE 1 SOP/1.0 GET 1 SOP/1.0 The number following the Message Type indicates if the message is being re-transmitted as the same message in the same Transaction. This number MUST be incremented by a sender whenever a message is re- transmitted. A receiver MAY give higher priority to re-transmitted messages. 8.1. Acknowledge Timeout This header indicates the time in seconds after which a SN MAY send a "reminder" 200 OK message to the Proxy, soliciting a COMMIT. After Retransmission Counter times transmissions of the 200 OK, the SN SHOULD consider the transaction cancelled and initiate rollback operations. This header SHOULD be sent in the Advertisement message to set the global value of the timeout. The header MAY also be sent in the CREATE, DELETE, TRANSFER requests to set the timeout per request basis depending on the time a Proxy anticipates it would take to complete certain operations. Acknowledge-Timeout: 30 8.2. Alternate Proxy Header This header is used to redirect a Client to another Proxy. This can happen if a Proxy knows that the Workflow Anchor (WA) for the Workflow has moved to another Proxy and the Proxy is configured not to forward requests to that Proxy. Alternate-Proxy: p2.provider.com 8.3. Cancel Timeout Header This header indicates the time in seconds after which a Proxy SHOULD send a cancellation for a request if a 200 OK or 100 Trying message has not been received. This header SHOULD be sent in the Advertisement message to set the global value of the timeout. The header MAY also be sent in the CREATE, DELETE, TRANSFER or UPDATE requests to set the timeout per request basis. Cancel-Timeout: 30 Dalela Expires July 4, 2012 [Page 27] Internet-Draft Service Orchestration Protocol January 2012 8.4. Commit Timeout Header This header defines the time in seconds after a response has been sent that a COMMIT is expected by the SN. Its behavior is described in Section 9.6. Commit-Timeout: 50 8.5. Content Type Header This header defines the kind of content carried in the SOP request. SOP messages are expected to carry SDF payloads. However, it is possible that other kinds of service description schemes may be used in conjunction with SOP. This header MUST be used to specify the type of application payload carried in the SOP message. Content-Type: application/sdf; charset=utf-8 8.6. Content Length Header This header defines length of content carried in the SOP request, computed in bytes. The length MUST NOT include SOP headers. It MUST be the length of the SDF payload carried in the SOP packet. Content-Length: 158 8.7. Distance Header This header helps in identifying the distance of a network entity from a receiver. It MUST be used in PUBLISH messages to advertize services. The value of this header MUST be incremented whenever a PUBLISH is forwarded. The receivers SHOULD use a shortest path to a service, and to avoid service routing loops. Distance: 1 8.8. Destination Header This header MUST be present in the TRANSFER messages. It is used to indicate the address of the destination SN that will be receiving a service. The address MUST conform to addressing in Section 5.2. Destination: default@sn.provider.com Dalela Expires July 4, 2012 [Page 28] Internet-Draft Service Orchestration Protocol January 2012 8.9. Exchange Header This header is used to identify the exchange within which a transaction is taking place. The use of Exchange identifiers helps to correlate cross-domain, multi-device or other complex orchestrations that may involve multiple devices or even brokers. This header MUST be present in all request-response messages. Exchange: 43shXui7236 8.10. From Header This header identifies the originator of the service request. It MUST indicate the initiator's address. Addresses MUST conform to SOP addressing in Section 5.2. From: default@p.provider.com 8.11. Node Type Header This header identifies the type of node in the SOP network. The header MUST have one of the following values: (a) "service-client", (b) "workflow-server", (c) "service-proxy" and (d) "service-node". This header is used in REGISTER, PUBLISH and SUBSCRIBE messages. In the REGISTER and PUBLISH messages it helps to identify the sender type and distinguish various types of registrations or publications. In the SUBSCRIBE message it helps the Proxy to determine which node's information must be forwarded to the requestor. Node-Type: service-node 8.12. Priority Header This header MAY be added by requestor to prioritize its processing over other pending messages. Priorities can be any number from 1 to 65535, with 65535 being the highest. This field may be used in conjunction with policy decisions in a cloud service network to prioritize certain requests over others. Priority: 5 8.13. Query Type Header This header MUST be used in GET requests to obtain information about a Task-ID, Workflow-Name, Workflow-ID, List of Workflow-IDs against a Workflow-Name, List of Task-IDs against a Workflow-ID or Name, etc. The header can have the following values: Dalela Expires July 4, 2012 [Page 29] Internet-Draft Service Orchestration Protocol January 2012 (a) "active-workflows" - all workflow-ids against a workflow-name. the Workflow-Name MUST be present in the request. (b) "active-tasks" - all task-ids for a Workflow-Name or Workflow-ID. The Workflow-Name and/or Workflow-ID MUST be present in request. (c) "workflow-name" - description of a Workflow in Tasks, specified by a Workflow-Name. The Workflow-Name MUST be present in request. (d) "workflow-id" - description of tasks that were performed in a particular instance of a Workflow, denoted by the Workflow-ID. The Workflow-ID MUST be present in the request. (e) "task-id" - description of the attributes that make up a specific Task referenced by the Task-ID. The Task-ID MUST be present in the request. Workflow-Name and Workflow-ID MAY be present. Query-Type: workflow-id 8.14. Publish Timeout Header This timer indicates the period at which a SN must publish its services to the Proxy regardless of change in service availability. Its behavior is described in detail in Section 9.7. Publish-Timeout: 500 8.15. Retry Count Header This header defines the number of times a SN SHALL send a 200 OK in response to a CREATE, DELETE, TRANSFER or UPDATE messages before receiving a COMMIT. On each retry, the Commit-Timeout MUST be expired before the retry is attempted. After completion of Retry Count number of retries, the SN MUST initiate a service rollback. This header SHOULD be sent in the ADVERTISE message and MAY be sent in individual CREATE, DELETE, TRANSFER or UPDATE messages. In the latter case, the count applies only to that particular Exchange. Retry-Count: 3 8.16. Requestor Header In some cases, the originator of a request may be different than the requestor. For instance, a Proxy may initiate a request using a non- SOP trigger. In these cases, it is important to include requestor's information in SOP messages. This information may be used for Dalela Expires July 4, 2012 [Page 30] Internet-Draft Service Orchestration Protocol January 2012 accounting, or other user-specific customizations. This header MAY be identical to the From Header. Requestor: service-client@customer.com 8.17. Registration Timeout Header This header indicates to SN the time within which it must register again. Behavior of this timer is described in the Section 9.1. Registration-Timeout: 10000 8.18. Service ID Header A Service ID MAY be used to refer to a particular instance of a virtual service. A Proxy MUST return a unique Service ID in response to a REGISTER. That ID MUST be used in future to identify services. A new Service ID MUST also be indicated by the WS in case of a new service creation. Moving services SHOULD retain the Service-ID. Service-ID: 8743435@compute Service-ID: 8743435@compute-resources.provider.com 8.19. Sequence ID Header This header MUST be present in all requests and SHALL identify the sequence number of requests of the same type. By adding sequence numbers, a receiver has the ability to identify which requests have come later. The sequence numbers MUST be reset after they have reached a maximum of 32 bits unsigned integer. Sequence-ID: 8624 CREATE 8.20. Source Header This header is used for service mobility and indicates the address of the source SN that will be transferring a service. Source: default@sn.provider.com 8.21. Subscribe Timeout Header This timer indicates the period at which a TS or WS must SUBSCRIBE for SNs or Clients regardless of change in their availability. Its behavior is described in detail in Section 9.9. Subscribe-Timeout: 500 Dalela Expires July 4, 2012 [Page 31] Internet-Draft Service Orchestration Protocol January 2012 8.22. Task ID Header This header identifies a unique type of configuration in the TS. A common ID may be used across a number of SNs. Configuration specific to SN would be passed based on the requestor's address in GET. Use of an ID allows all configurations to be stored centrally. Task-ID: 67439375 8.23. Timestamp Header This header MAY be added by requestor to identify the time of the request origination. It MAY be used to drop requests that are older than the specified expiry time period. The timestamp will specify the expired seconds according to UTC since January 1, 1961. Timestamp: 1285162130 8.24. To Header This header identifies the destination of the service request. It must indicate a user-id to which the service request is targeted. To: default@p.provider.com 8.25. Transfer Mode Header This header is used in the REGISTER message. The SN identifies the manner in which it can support service mobility. If the SN is capable of transferring live state to another SN, it SHOULD set this header to "stateful". If the SN cannot transfer live state, it must set this header value to "stateless". In stateless transfers, a service instance is created and the old one is deleted. Transfer-Mode: stateful 8.26. Via Header This header MUST be inserted by every SOP node through which the SOP request traverses, provided the SOP node is not acting as a stateless proxy. The forwarder MUST insert its SOP address and a random branch parameter to identify the transaction between the peering entities. The header will also have the SOP version and indicate the transport over which SOP message is transmitted. Via: SOP/1.0/UDP default@sb.provider.com;branch=k9DjR5lbcw Dalela Expires July 4, 2012 [Page 32] Internet-Draft Service Orchestration Protocol January 2012 8.27. Workflow ID Header This header identifies a unique instance of a Workflow. A workflow may be customized for a user based on user-specific policies. The Workflow ID is the specific customized instance of a workflow. It may reference a stored workflow in the WS, or with sufficient number of parameters so as to compute the workflow at a later time. Workflow-ID: 68743693@provider.com 8.28. Workflow Name Header This header identifies a unique Workflow within a provider. The Workflow Name allows a client or Proxy to request a workflow execution. A Proxy SHOULD send PUBLISH messages listing available workflows. Workflow Name MUST identify the provider who supports the workflow. This allows workflow names to overlap across providers. Workflow-Name: X32mnTrUwq@provider.com 8.29. Workflow Server Header This header provides the address of a workflow server that a SN or Proxy may query for processing a request, such as to obtain a task description. This header should be used in conjunction with the Task- ID header. Workflow-Server: Workflow-Server.provider.com 9. Timers and Counters 9.1. Retransmission Counter This counter defines the number of retransmissions for a request before a CANCEL is sent, or for a response before a COMMIT is expected. The value of counter SHOULD be set by the Retry-Count header globally in the ADVERTISE message or per transaction in CREATE, DELETE, TRANSFER or UPDATE messages. 9.2. Acknowledge-Timeout This indicates the time after which a SN may send a "reminder" 200 OK message to the Proxy, soliciting a COMMIT. After Retransmission Counter retries of the 200 OK, the SN would consider the transaction cancelled and initiate rollback operations. Dalela Expires July 4, 2012 [Page 33] Internet-Draft Service Orchestration Protocol January 2012 9.3. Register-Timeout This indicates the maximum time for which a Proxy will honor a registration. The SN must register with the Proxy within that time. If REGISTER is not received before timer expiry, the Proxy SHOULD mark the SN and its services unavailable. On receiving a REGISTER that matches its Capabilities, the Proxy shall send a 200 OK. 9.4. Advertise-Timeout This indicates the time after which a Proxy will send ADVERTISE. If the Proxy indicated time period for the ADVERTISE has expired for a successive 3 times, a SN MAY transmit a DISCOVER requesting for Proxies that can cater to its service domains. This timer SHOULD be set by the Advertisement-Timeout header in the ADVERTISE message. 9.5. Cancel-Timeout This timer is started after sending any request and reset after the receipt of any provisional or final response (such as 100 Trying or 200 OK). If a provisional or final response is not received, the sender MUST transmit the request a total of Retransmission Counter times. If a provisional or final response is still not received, the sender SHALL send a CANCEL and will terminate the transaction. This timer SHOULD be set by the Cancel-Timeout header in the ADVERTISE message and it may be overridden on per transaction basis in the CREATE, DELETE, TRANSFER and UPDATE messages. 9.6. Commit-Timeout This timer will be started by a responder after sending a 200 OK on transactions where a COMMIT is expected (CREATE, DELETE, TRANSFER, etc). After the timer expires, a 200 OK will be retransmitted up to a max of Retransmission Counter times. When the Commit-Timeout has expired Retransmission Counter times (after sending a 200 OK) the responder SHALL silently discard (or rollback) the changes it had performed earlier. This timer SHOULD be set by the Commit-Timeout header in the ADVERTISE message and it may be overridden on per transaction basis in the CREATE, DELETE, TRANSFER and UPDATE messages. 9.7. Discover-Timeout This timer will be started by a SN immediately after startup or after 3 successive timeouts of the Advertise-Timer (the Proxy has not sent Dalela Expires July 4, 2012 [Page 34] Internet-Draft Service Orchestration Protocol January 2012 ADVERTISE 3 successive timeouts). When the Timer expires, the SN SHALL transmit the DISCOVER message. The timer SHALL be reset upon receipt of a ADVERTISE that matches the SN's SDN. This time SHALL have a fixed value of 15 seconds, because the timer is required to discover a Proxy and prior to receiving an ADVERTISE. 9.8. Publish-Timeout This timer defines the time period within which a SN must send its service updates, regardless of any change in the service status. This will refresh a Proxy's service database, and prevent stale information. This timer SHOULD be set by the Publish-Timeout in the ADVERTISE message. Publish-Timeout: 500 9.9. Subscribe-Timeout This timer defines the time period within which a WS or TS must send a SUBSCRIBE requesting for updates on SN or Client availabilities. This will refresh a Proxy's subscribe database, and prevent stale information. This timer SHOULD be set by the Subscribe-Timeout in the ADVERTISE message. Alternately Subscribe-Timeout: 5000 9.10. Retransmit-Timeout This timer defines the time period within which a WS or TS must send a 100 TRYING to acknowledge a request. If the 100 TRYING response is not received within this time, the sender SHOULD retransmit the request up to a maximum of NRetransmit times. This timer SHOULD be set by the Subscribe-Timeout in the ADVERTISE message. Subscribe-Timeout: 5000 10. Message-Header Relationships This section describes which messages depend on which headers. The following convention is used. "M" denotes "mandatory", "O" denotes "optional" and "I" denotes "ignore message" (drop it if it is seen). +-------------------------+-------------------------------------+ | Header Name |A|C|C|C|D|G|D|P|R|S|T|U|W|1|2|3|4|5|6| | |D|A|O|R|E|E|I|U|E|U|R|P|O|X|X|X|X|X|X| | |V|N|M|E|L|T|S|B|G|B|A|D|R|X|X|X|X|X|X| | |E|C|M|A|E| |C|L|I|S|N|A|K| | | | | | | | |R|E|I|T|T| |O|I|S|C|S|A|F| | | | | | | Dalela Expires July 4, 2012 [Page 35] Internet-Draft Service Orchestration Protocol January 2012 | |T|L|T|E|E| |V|S|T|R|F|T|L| | | | | | | | |I| | | | | |E|H|E|I|E|E|O| | | | | | | | |S| | | | | |R| |R|B|R| |W| | | | | | | | |E| | | | | | | | |E| | | | | | | | | | +---------------------------------------------------------------+ | Acknowledge-Timeout |O|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Altenate-Proxy |I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|O|I|I|I| | Content-Length |O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O| | Cancel-Timeout |O|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Commit-Timeout |O|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Content-Type |O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O| | Distance |I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I| | Destination |I|I|I|I|I|I|I|O|I|O|I|I|I|I|I|I|I|I|I| | Exchange |O|M|M|M|M|M|O|M|M|M|M|M|M|M|M|M|M|M|M| | From |M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M| | Node-Type |I|I|I|I|I|I|I|M|M|M|I|I|I|I|I|I|I|I|I| | Priority |I|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Publish-Timeout |O|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Retry-Count |O|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Query-Type |I|I|I|I|I|M|I|I|I|I|I|I|I|I|I|I|I|I|I| | Requestor |I|I|M|M|M|I|I|I|I|I|M|O|I|I|I|I|I|I|I| | Registration-Timeout |M|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Service-ID |I|I|I|I|I|I|I|I|I|I|I|I|I|I|O|I|I|I|I| | Sequence-ID |O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O| | Source |I|I|I|I|I|I|I|I|I|I|M|I|I|I|I|I|I|I|I| | Subscribe-Timeout |O|I|I|O|O|I|I|I|I|I|O|O|I|I|I|I|I|I|I| | Task-ID |I|I|O|O|O|O|I|I|I|I|O|O|I|I|O|I|I|I|I| | Timestamp |O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O|O| | To |M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M|M| | Via |O|M|M|M|M|M|O|M|M|M|M|M|M|M|M|M|M|M|M| | Workflow-ID |I|I|O|I|I|O|I|I|I|I|I|I|O|I|O|I|I|I|I| | Workflow-Name |I|I|I|I|I|I|I|I|I|I|I|I|M|I|I|I|I|I|I| | Workflow-Server |I|O|O|O|O|I|I|I|I|I|O|O|O|I|I|I|I|I|I| +---------------------------------------------------------------+ 11. Security Considerations Text-based messages can be snooped or modified in transit. Encryption and authentication are essential with SOP. SOP authentication can be done along same lines as SIP [SIP]. Similarly, SOP can use IPSec, TLS or other encryption and privacy mechanisms already being used with HTTP. A description of these mechanisms is left to a later effort. Dalela Expires July 4, 2012 [Page 36] Internet-Draft Service Orchestration Protocol January 2012 12. IANA Considerations An IANA port will be requested for the SOP destination port. A request to IANA to register SOP headers will be sent when the specification is closer to being finalized. 13. Conclusions SOP describes a formal, extensible and flexible framework for orchestrating services in an interoperable way. Using SOP it should be possible to define new services and service domains, and advertise and consume them across provider and consumer boundaries. Interoperable ways of creating, delivering and consuming services is essential for cloud. We envision that SOP can be an essential ingredient of Cloud Proxies and Border Gateways, to exchange services across multiple private, public, hosted, community and other clouds. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 14.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 [SDF] Service Description Framework http://www.ietf.org/id/draft-dalela-sdf-00.txt 15. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Dalela Expires July 4, 2012 [Page 37] Internet-Draft Service Orchestration Protocol 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 38]