Network Working Group A. Dalela Internet Draft Cisco Systems Intended status: Standards Track M. Hammer Expires: July 2012 January 4, 2012 SOP Network Architecture draft-dalela-sop-architecture-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 Network Architecture 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 network level deployment architecture to connect users and providers. This document describes functionality partitioning in network deployment and the different advantages of using distributed functionality deployments. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Terms and Acronyms.............................................4 4. Problem Statement..............................................5 5. Solution Approach..............................................8 6. Architecture Description......................................10 6.1. Functional Architecture..................................10 6.1.1. Proxy...............................................11 6.1.2. Workflow Server.....................................12 6.2. Deployment Architecture..................................12 6.2.1. Types of Proxies....................................13 6.2.1.1. Requesting Proxy (RP) and WS (RWS).............13 6.2.1.2. Locating Proxy (LP) and WS (LWS)...............14 6.2.1.3. Serving Proxy (SP) and WS (SWS)................14 6.2.2. Interconnecting Proxies and WSs.....................15 6.2.3. Workflow Branching and Anchoring....................16 6.2.4. Distributed Workflow................................18 7. Security Considerations.......................................19 8. IANA Considerations...........................................19 9. Conclusions...................................................19 10. References...................................................19 10.1. Normative References....................................19 10.2. Informative References..................................19 11. Acknowledgments..............................................20 1. Introduction This document describes network architecture and deployment models for supporting service orchestration. The architecture and deployment models are driven by the following main requirements: - Security of the Service Network. A provider needs to ensure that its service network is secure from external attacks. To this end, the provider may need to hide service topologies, and inspect or Dalela Expires July 4, 2012 [Page 2] Internet-Draft SOP Network Architecture January 2012 modify service transactions on the fly. Network architecture will define how topology hiding and security are achieved. - Policy Control of Service Network. Service deployments may cross customer and provider boundaries as described in Service Orchestration Protocol (SOP) requirements [REQT]. Each customer or provider may wish to enforce policy rules for service usage at ingress and egress points. An architecture definition will define how customers and providers can policy control services. - Separate Service-Dependent and Service-Independent functions in the network. A service consumer or provider should not have to upgrade their orchestration infrastructure in order to deploy or use a new service. Separation allows new service deployment without disrupting the network of existing services. - Scaling the Service Network. To scale service across many consumers, service type and locations, distribution of service functionality is needed. For instance, service-dependant intelligence for a set of customers might be stored in one network element. Or, all intelligence related to one class of services may be centralized in one network element. Or, all customers in one particular geography or location may access services from one particular network element. Service orchestration architecture should support these and other types of deployment models. - Bundling and Tiering of Services. Services often come in bundles. If we provision a Virtual Machine, we also need to provision storage, QoS, access control, intrusion prevention, etc. Some services may need to use other services in turn. Architecture should define how service tiering and bundling is achieved. - Service Network Reliability. When services are critical to the working of an organization, it is important to define how users will be able to receive continued service even in case of network failures. Architecture should help system reliability. This document describes a SOP network architecture that can be employed to fulfill these requirements. 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]. Dalela Expires July 4, 2012 [Page 3] Internet-Draft SOP Network Architecture January 2012 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]. Service Node (SN): A Service Node is any hardware or software entity that can be made available for use as a service. A Service Node may be associated with an "agent" that receives orchestration requests and may in turn execute them on behalf of the service. Use of an agent abstracts service logic from rest of the network. Proxy - this is the service-independent network element that accepts Client or other Proxy requests and forwards them to services or other proxies. The Proxy may forward requests to SNs, Workflow Servers or other Proxies. A network of interoperable clouds may use multiple proxies. A Proxy may inspect or modify packets in transit. Workflow Server (WS) - this is the service-dependent network element and contains Workflow definitions along with policies to validate or modify Workflow requests. Requesting Proxy (RP) - this is the SOP Proxy that makes service requests. The RP may forward them to the Locating Proxy (LP). Locating Proxy (LP) - this is the SOP Proxy that performs load- balancing, locating and security functions in SOP network. It forwards received requests to the Serving Proxy (SP). Serving Proxy (SP) - this is the SOP Proxy that actually controls a particular type of service orchestration. Requesting WS (RWS) - this is the WS associated with the RP. Locating WS (LWS) - this is the WS associated with the LP. Serving WS (SWS) - this is the WS associated with the SP. Workflow Anchor (WA) - this is the Proxy that controls the Workflow execution. All Task branching must take place at the Anchor. Dalela Expires July 4, 2012 [Page 4] Internet-Draft SOP Network Architecture January 2012 4. Problem Statement The key problem for orchestration architecture is how to ease the creation of new services by (a) tiering service one on top of another, (b) bundling multiple independent services as a single use- case, (c) customization of a single service for different users. Tiering refers to one service using another service for its functioning (e.g. SaaS might use PaaS, PaaS might use IaaS, and SaaS or PaaS will not work without IaaS). Bundling refers to two or more services that work independently but have improved functionality by combining (e.g. network, security and compute combine to deliver improved functionality to the user). Customization means adding functionality to a service without tiering or bundling (e.g. a security device may be improved with intrusion detection). A realistic service deployment requires complex service combinations. E.g., if we are provisioning a VM, we may also need to provision network attached storage, security rules that limit access to that storage, firewalls and access control that restricts access to the VM, bandwidth from a suitable starting point to the VM, user provisioning for who can access the VM, load-balancers and WAN optimization techniques, intrusion detection and prevention or techniques to log and report accesses to a service, etc. Currently, services are combined by combining lower level APIs into higher-level APIs. The inputs to these APIs must follow several cross-domain semantic "rules", without which the API combination will not give a usable service. For example, the IP of a host must belong to the subnet on the switch, because otherwise packets will never be routed. The IP access-list on the switch must permit the IP address on the host, otherwise packets will be dropped. Open ports on a host must also be open on the firewall because otherwise packets will never be received. There are many such "rules" to be followed. Each customer may design their own rules, restricting the service design per their needs. APIs don't allow us to define these rules in the abstract. They must be embedded in the input to the APIs. Orchestration rules deal with the "semantics" of a service, while APIs deal with the syntax. For any given semantics, there are several possible syntaxes to achieve it. Current cloud technology focuses on the syntax and not the semantics. Thus, the same service will require use of different APIs across different providers. This is unnecessary because the users don't care about the APIs. They care about the service semantics, and the rules of orchestration. How these rules are implemented, is totally irrelevant from the user viewpoint. Dalela Expires July 4, 2012 [Page 5] Internet-Draft SOP Network Architecture January 2012 From a provider's viewpoint, it is important to integrate hardware and software from many possible vendors in the same way. To achieve this, it is important to have a standard interface to that hardware and software that the provider can use to orchestrate. As long as the interface is standard, it does not matter which type of API flavor is used to control the hardware or software. The provider does not care how a hardware or software vendor implements the interface on their side, as long as the standard interface is available. +---------------------+ | Service Semantics | Customer View | Orchestration Rules | +---------------------+ | | +---------------------+ | Service Control | Implementation View | Software API Format | +---------------------+ | | +---------------------+ | Standard Interface | Vendor View | Protocol Messages | +---------------------+ Figure-1: 3-Tier Orchestration Stack Figure-1 shows an ideal 3-tier orchestration stack, where users provide orchestration rules and vendors provide a standard interface to their services. In the middle of the orchestration stack are software objects that translate the user given rules into standard interfaces to the multi-vendor services. The properties of the software objects are not visible either to the users or to the service vendors. This decoupling between different views allows independent evolution and backwards compatibility. It means that the orchestration rules are portable and a user can take get the same services from different providers. The provider can integrate many software-hardware products. The software that links semantic rules with the standard service interfaces can evolve independently. In current cloud technology, all three orchestration tiers are collapsed into a single API construct. The user sees APIs which is an implementation view stretching all the way into the service itself. If the API changed, the user will need to adapt to a new API and the vendor will have to implement the new API. This makes cloud extremely Dalela Expires July 4, 2012 [Page 6] Internet-Draft SOP Network Architecture January 2012 inflexible to interoperation across boundaries. The central problem of cloud control is that we need to move a single-tier orchestration model to the 3-tier model shown in Figure-1. Use of APIs as end-user interface hinders fast service customization. Each user encodes their service rules using APIs, but the toolset available to the user can only validate the syntax of the API but not its semantics. That means while the APIs can be compiled to be syntactically correct, the user cannot know that on executing those APIs the service will work as desired. We need a "semantic compiler" to achieve that. The rules in the "semantic compiler" will need to validate that the IP on the host is part of the subnet on the switch, that the ports on the host are open on the firewall, that IP of the host is part of permitted access-lists, etc. This semantic compiler can be customized by each provider and customer. That is, they can define their own rules of orchestration. Customer Provider +-------------+ +-------------+ | Service | Brick and Mortar | Simple | | Combination |--------------------| Services | | Complexity | Low-level APIs | Supported | +-------------+ +-------------+ Figure-2: End-User Deals with Complexity In the API approach, a provider exposes low-level APIs using which developers can build customized services. This approach pushes the complexity of service creation from the provider into the customer. A customer has to invest in building these custom solutions and thereby be responsible for the design of service. This is shown in Figure-2 where a customer owns the complexity of service creation. Customer Provider +-------------+ +-------------+ | Customized | Customized | Service | | Service |--------------------| Combination | | Combinations| High-level APIs | Complexity | +-------------+ +-------------+ Figure-3: Provider Deals with Complexity If, however, the provider decides to incorporate these custom solutions as part of their offerings, the complexity in the Orchestrator grows rapidly. The complexity grows linearly with the number of unique combinations. The complexity grows exponentially with the number of services within a combination. The rapid increase Dalela Expires July 4, 2012 [Page 7] Internet-Draft SOP Network Architecture January 2012 in complexity makes services brittle and hard to modify. This is shown in Figure-3 where the provider owns the complexity of service variety being created for various types of customers. Both architectures for building new services are not optimal. They either complicate the user-side or the provider-side of services. The 3-tier architecture shown in Figure-1 on the other hand provides an optimal scheme to creation of new services. 5. Solution Approach Our solution involves the implementation of the 3-tier orchestration architecture through two functional components shown in Figure-4. +---------------------+ +---------------------+ | Service Semantics | | Workflow Server | | Orchestration Rules | |=====================| +---------------------+ | Service-Dependant | | | Orchestration Rules | | | User + Provider | +---------------------+ | Service Definitions | | Service Control | +---------------------+ | Software API Format | +---------------------+ +---------------------+ | Orchestration Proxy | | |=====================| | | Service-Independent | +---------------------+ | Orchestration | | Standard Interface | | Execution Engine | | Protocol Messages | | Protocol Interfaces | +---------------------+ +---------------------+ Figure-4: Orchestration Components The service-independent network element (Orchestration Proxy) is unaware of service, user or policy nuances. It is the execution engine for orchestrating services, and has protocol interfaces to other Proxies or to service end-points. The orchestration rules of a service are defined in the service-dependent network element (Workflow Server). This contains all the policies according which the service will be orchestrated. The Workflow Server delivers an orchestration "master-plan" or workflow to the Orchestration Proxy to execute. The Proxy executes the workflow and reports back status. The service, user and policy information is encoded in the Workflow Server in an abstract language like XML. We term an XML document that describes a service bundle a "Workflow". Workflows are comprised of Tasks, which represent individual acts of orchestration on individual Dalela Expires July 4, 2012 [Page 8] Internet-Draft SOP Network Architecture January 2012 service elements. A Workflow represents the order in which the Tasks must be executed. Each Task in the Workflow contains a definition of actions that need to be taken for that task. Each Workflow can be referenced by a Workflow Name. A user requests a service bundle by invoking the workflow referenced by the Workflow-Name. Customer Provider +--------------+ +---------------+ | Workflow | | Workflow | | Server | | Server | +--------------+ +---------------+ | | | | +--------------+ +---------------+ +-----------+ | Service | User Friendly | Service | | Simple | | Orchestration|--------------------| Orchestration |--| Services | | Proxy | High-level APIs | Proxy | | Supported | +--------------+ +---------------+ +-----------+ Figure-5: Complexity Abstracted into XML Workflows One or multiple Workflow Servers (WS) may be situated at various points in the network. The WS can dereference a Workflow Name into an XML document comprised of Tasks. The WS can perform service-specific validations of the Workflow request against the service specific syntax and semantic rules stored in the WS. If the language to describe syntax and semantics of services has been standardized, the WS can support any number of new service combinations through configuration in the WS alone. These configurations will create a new Workflow in the WS, and specify rules for validating it. Neither the Proxy nor the WS need to be upgraded to support new services. With a XML definition of Workflows and Tasks, validation rules can be easily defined. For example, XML Schema Definition [XSD] can be used to validate syntax and Object Constraint Language [OCL] to validate semantics of a Workflow request. When a Workflow request arrives, the requested Workflow can be validated against the associated schemes already defined in XML or other abstract languages. If a request fails validation according to syntax and semantic rules already defined in the WS, the request MAY be rejected. The rules may also specify how to modify all or selected requests before forwarding them downstream. The collection of all the syntax and semantic rules constitute the "policy" framework for service orchestration. This policy framework may be centralized at the provider, at the customer or distributed between the provider and customers. Accordingly, the requests may be modified and/or validated multiple times. Dalela Expires July 4, 2012 [Page 9] Internet-Draft SOP Network Architecture January 2012 To add a new service, we don't need to create a new API combination. Rather we can add (through configuration) new XML documents to define a service and validate syntax and semantics of the service request. New services can thus be added through configuration alone. With the ability to define and validate Workflows, a user or provider can create service bundles on-demand. The WS stores all user or provider defined Workflows, which are referenced by a Workflow-Name. 6. Architecture Description This section covers two architecture flavors. First, we describe a Functional Architecture that partitions SOP functionality into separate network elements. This partitioning achieves the service- dependant and service-independent separation at the network level. Second, we describe a Deployment Architecture that allows a provider to scale their service network with security and policy control. 6.1. Functional Architecture | | | Customer | Provider 1 | Provider 2 | | | | +----------+ | +----------+ | +----------+ | | Workflow | | | Workflow | | | Workflow | | | Server | | | Server | | | Server | | +----------+ | +----------+ | +----------+ | | | | | | | | | | | | | +-------+ | +-------+ | +-------+ | | Proxy |----|-------| Proxy |-------|------| Proxy | | +-------+ | +-------+ | +-------+ | | | / | \ | / | \ | | | / | \ | / | \ | | | / | \ | / | \ | +-------+ | +----+ +----+ +----+ | +----+ +----+ +----+ | | User | | | SN | | SN | | SN | | | SN | | SN | | SN | | +-------+ | +----+ +----+ +----+ | +----+ +----+ +----+ | | | | Figure-4: SOP System Architecture The SOP network comprises of two types of network elements: a SOP Proxy and a Workflow Server (WS). The Proxy deals with service- independent aspects of orchestration while the WS contains the service-dependant features. These two elements interact using SOP. Dalela Expires July 4, 2012 [Page 10] Internet-Draft SOP Network Architecture January 2012 6.1.1. Proxy A Proxy performs Service Routing. When users request a service, the Proxy will route the request to the right location. To do service routing, the Proxy discovers and monitors services. It authenticates services and users, so that unwanted users or services cannot get into the service routing database. A Proxy can forward packets to Service Nodes, Workflow Servers, other Proxies, and responses back to Proxies and Users. The Proxy may statefully inspect packets and insert or remove headers. But, the proxy does not have service- specific intelligence to orchestrate services. Proxies may operate in one of two modes: Transparent and Aggregated. A Transparent Proxy does not aggregate services; it only forwards all messages transparently. An Aggregated Proxy would aggregate services and publish them as aggregates. In the Aggregated Mode, a single Proxy may publish a wide variety of services to their users, although these services are in turn managed by other Proxies. A Proxy is expected to perform the following functions: - Advertize its presence as a network element that is capable and willing to Proxy for service transactions for certain types of services (service-specific Proxies should be possible). - A Proxy should have the ability to connect to other Proxies and exchange service related information in a way similar to how it might do with a service client. This allows a distributed network of service proxies to be built that exchange service information. - Discover servers and their service capabilities. After discovery, a Proxy should create a Service Registry that clients or other Proxies can query to discover types of services available. - Discover user locations and presence status through user registrations and indication of service interests. Location is often a key consideration in delivering services, since certain services may be routed differently based on locations or may be forbidden access or allowed restricted access only. - Ability to connect to policy databases that determine the rules by which a service request is routed to the next hop, or how a service request may be modified or translated prior to routing. Policy routing of service requests is a very key function by which customers and providers can control service transactions through single points of control in the network. Details on the nature of these policy databases should be described separately. Dalela Expires July 4, 2012 [Page 11] Internet-Draft SOP Network Architecture January 2012 - Authentication, Authorizing and Accounting of services should be performed by the Proxy. A Proxy may intercept requests and challenge the client to authenticate itself. It may then lookup a policy database to validate that the user is authorized to make service transactions. After services have been created, periodic accounting must also be performed. Existing protocols such as RADIUS or DIAMETER should be used for this purpose. 6.1.2. Workflow Server The WS stores service-dependant intelligence. This includes service authorization, SLAs for those services, location preferences, charging policies, processes for fulfilling requests, etc. These policies should be available as syntax and semantics validation procedures that can be applied by the WS to received requests. If the validation fails, the requests may be rejected. To apply customer specific rules, the WS must know about users and their location. To apply service specific rules, the WS must know about service availability and location. The WS should receive this information from the Proxy on a periodic basis or whenever it changes. The WS MUST subscribe for updates with the Proxy. A WS may automatically trim or expand a requested Workflow prior to execution. For example, to a VM creation workflow, the WS may add tasks for storage, access control, QoS, load balancing, etc. even though the end-user hasn't requested them. These policies may be defined by the user, by the provider, or mutually agreed upon as a SLA. This greatly simplifies the creation of service bundles. Once a Workflow has been defined, the Proxy or Service Nodes can download the Workflow and Task definitions from the WS. In case of failures or service termination, the WS will determine action reversal, by flipping the individual tasks in the correct order. 6.2. Deployment Architecture Proxies and WSs may be designated for specific customers, providers, service types, etc. One or both of these network elements may be deployed at multiple points in the network, including but not limited to (a) customer/provider egress, (b) customer/provider ingress, (c) customer/provider intranet. The Proxy and WS interaction MAY be any- to-any. Thus, one Proxy may interact with multiple WSs for multiple service types. Similarly, a WS may serve one type of service- dependant rules to multiple Proxies that support the same service. Dalela Expires July 4, 2012 [Page 12] Internet-Draft SOP Network Architecture January 2012 If proxy does not interact with any WS, it acts as a stateless-proxy that will not modify the orchestration messages in transit. 6.2.1. Types of Proxies We define three types of Proxies based upon their different roles in a service network. These types are shown in Figure-5 and described in detail in the following sections. Note that these are logical and functional distinctions and one physical network element could play the role of multiple Proxies, or all Proxies may be combined into a single network element in an implementation. The separation between types of Proxies makes it easier to discuss the functions of a Proxy in different kinds of deployments. Each Proxy may be managing some SNs and/or Users. +-------------+ +--------------+ +--------------+ | Requesting | | Locating | | Serving | | Workflow | | Workflow | | Workflow | | Server | | Server | | Server | +-------------+ +--------------+ +--------------+ | | | | | | +-------------+ +--------------+ +--------------+ | Requesting | | Locating | | Serving | | Proxy |-----------| Proxy |-----------| Proxy | +-------------+ +--------------+ +--------------+ Figure-5: Three Types of Proxies 6.2.1.1. Requesting Proxy (RP) and WS (RWS) This Proxy is typically located at a Client premise. The Client may be an end-user, a provider who sources services from other providers and combines them with their own services, or a 3rd party provider who only aggregates services from multiple providers. In these cases, the RP would be located at the edge of a customer or provider's networks, and play functions of egress control. A RP may also be located inside a provider's network, when it requests services from other Proxies. For example, a SaaS Proxy may be a RP to query IaaS services, for its SaaS services. In this case, the Requesting Proxy would be located inside a provider's network. The RWS associated with the RP should be used to validate the requests before allowing them to be forwarded. For example, the RWS may be used to validate a customer's requests against the policies Dalela Expires July 4, 2012 [Page 13] Internet-Draft SOP Network Architecture January 2012 provisioned for a given user before forwarding them. Or, the RWS may be used by a provider to validate provider-to-provider requests before sending them to another provider. The validations may be defined unilaterally or based upon agreements or SLAs defined prior. 6.2.1.2. Locating Proxy (LP) and WS (LWS) The LP aggregates service information and publishes aggregated information outside. The LP may be used to hide the service topology inside a provider. For instance, a provider who supports multiple services, may only publish its LP address and internally route the requests to a dynamically or policy-selected SP. The LP can also be used to implement high-availability of services by routing service requests to where the requests are best fulfilled. The LP may statefully inspect received requests and authenticate the senders before forwarding the requests further. It may rate-limit requests from a particular source, and may have the intelligence for intrusion detection and prevention, for protecting the internal network from denial of service (DoS and DDoS) attacks, etc. The rest of the network behind the LP may then assume that packets entering them are secure. This obviates need for every service authenticating the user requests, and building security defenses. The LWS associated with the LP may have rules to forward the requests based on policies. For instance, the LWS may determine that service requests from a certain customer must be always directed to a definite location. The LWS may choose the nearest service creation location, or route to a location that has resources available. 6.2.1.3. Serving Proxy (SP) and WS (SWS) The SP may be defined to cater to specific customers, service-types or locations. For instance, there may be a SP for a group of customers who have been guaranteed a certain level of service. A SP may orchestrate services in a given geography. Or, it may deal with a specific type of services such as compute or storage. The SP can control orchestration across multiple resources or resource domains. For instance, a SP may orchestrate services across compute, storage, network, security, etc. It can also delegate the tasks of individual service components to that domain specific orchestrator. It may instantiate multiple service instances based on a single request, and may be used to setup a complete virtual datacenter on a single request. It shall handle error or failure scenarios and trigger rollback actions. The SP must discover services, allow service registrations, and publish aggregates of Dalela Expires July 4, 2012 [Page 14] Internet-Draft SOP Network Architecture January 2012 services to upstream LPs. The SP is also responsible for accounting for service usage and must generating charging records. A SP may become the anchor for complex service orchestration that are outside the domain of its own control. In this case, the SP will play the role of a RP, and make requests to a LP to route requests outside its domain of control. For instance, a SP that creates a pool of virtual machines may run out of resources and direct a request to a LP to find it additional resources in another location. The SWS associated with the SP should have rules to orchestrate particular types of service requests. It would perform per-service validations of Workflows, checking if a user is authorized to make those service requests, and if those requests are well-formed. Service-specific syntax and semantic rules reside in the SWS. It may modify Workflow requests based on service or user policies. 6.2.2. Interconnecting Proxies and WSs The connections between Proxies and WSs may not be one-to-one as shown above. A Proxy may connect to multiple WSs for different Workflows and a WS may serve multiple Proxies. A distribution of Proxies and WSs creates optimal load-balancing. Each WS SHOULD advertize the Workflows it supports to the Proxy. The WS SHOULD also advertize class of users and service domains it can support. A Proxy can use this information to forward appropriate service requests to appropriate WSs. The WS and Proxies use SOP to exchange orchestration information. +--------+ +--------+ +--------+ | WS1 | | WS2 | | WS3 | +--------+ +--------+ +--------+ | \ | \ | | -------------\ | -------------\ | +--------+ +--------+ +--------+ | Proxy1 |--------| Proxy2 |---------| Proxy3 | +--------+ +--------+ +--------+ Figure-6: Many-to-Many Relation between Proxy to WS A Proxy must also advertise the Workflows it receives from the WS to other Proxies. This way, a Proxy can know how to reach the Proxy that can execute a Workflow, and be able to route requests to it. Dalela Expires July 4, 2012 [Page 15] Internet-Draft SOP Network Architecture January 2012 6.2.3. Workflow Branching and Anchoring When a complex Workflow spans across multiple SNs (compute, storage, network, security, software, etc.) there has to be a point where the Workflow is broken into individual Tasks for execution. We call the decomposing of a Workflow into Tasks "Workflow Branching". The point in the network where the Workflow is decomposed into Tasks is called the "Workflow Anchor". The component Tasks in a Workflow are defined by the WS. These Tasks must be initiated by a Proxy. The initiator Proxy for all Tasks in the Workflow is the Workflow Anchor. The need for an Anchor arises because once a Workflow has been branched into Tasks, other downstream entities don't have the complete picture of the Workflow and they cannot own the Workflow as a whole. The Workflow Anchor owns the Workflow. It is responsible for (a) executing the right tasks, (b) executing these tasks in the correct order (c) correctly accounting for tasks after execution, (d) handling failures in the right way when they arise, etc. +--------+ +-------| TASK-1 | | +--------+ +----------+ | WORKFLOW | Workflow | | +--------+ -------------->| Anchor |----+-------| TASK-2 | +----------+ | +--------+ | | +--------+ +-------| TASK-3 | +--------+ Figure-7: Workflow Branching into Tasks The Workflow Anchor can be located at multiple points in the network, such as the Client, Customer's Proxies, Provider's Proxies, etc. For instance, the Client of services can be the Anchor and in this case the Client will have to own the workflow execution, service accounting and failure handling. The Customer's Proxies and Provider's Proxies may inspect or authenticate the messages in transit but they may have no understanding of the complete sequence of tasks, and will not be able to validate if the Client is executing the right sequence of actions. If the Client is unreliable, it may skip service accounting. The Client may perform invalid operations which may not lead to usable services, and then not account for these. This shows the importance of Anchor placement, and the trust relationship between the Provider and the Workflow Anchor. Dalela Expires July 4, 2012 [Page 16] Internet-Draft SOP Network Architecture January 2012 To address the trust issues, we might decide to Anchor the Workflow in the Customer's Proxy or the Provider's Proxy. Now, the Client must request the Workflow execution from one of these Proxies. The Client should refer to the Workflow through some Workflow Name in order for the receiving Proxies to validate if the request is correctly formed. Now, the Workflow execution is owned by the Proxies (although the Client may know the Workflow composition and can frame the Workflow request). The Proxy will validate the Workflow before branching Tasks. The Proxy will ensure accounting and failure handling. To execute any Workflow, the Workflow Anchor must be trustworthy. Depending on the deployment scenario, the Anchor may be situated at various points in the network. For personal clouds, the Client may be a valid Anchor. For private enterprise clouds, the Customer's Proxy may be a valid Anchor. For public clouds, the Provider's Proxy may be the only trustworthy anchor. For community clouds, the end Service Node may be the trustworthy anchor. Depending on where the Anchor is located, Workflow branching will take place at the Anchor. +--------+ +----------+ +----------+ +---------+ | Client | | Customer | | Provider | | Service | | |<------>| Proxy |<------->| Proxy |<----->| Node | +--------+ +----------+ +----------+ +---------+ Personal Private Public Community Cloud Cloud Cloud Cloud Anchor Anchor Anchor Anchor Figure-8: Possible Workflow Anchor Locations Network elements that are upstream from the Anchor MUST NOT be able to branch the Workflow into Tasks. These elements may validate the Workflow but they are not responsible for doing so. The Anchor MUST be responsible for validating the Workflow and correct execution. There SHOULD be an interface between Clients and Proxies, and between Proxies, through which they can request complete Workflows. The Workflow request received at the Anchor may be incomplete. The request may specify parameters about a VM, and may leave the details of network, storage and security to the Anchor. The request received at the Anchor is treated as indicative by the Anchor. The Anchor SHOULD forward the received request to the WS and obtain a complete and accurate description of the Workflow prior to executing it. Dalela Expires July 4, 2012 [Page 17] Internet-Draft SOP Network Architecture January 2012 6.2.4. Distributed Workflow It should be possible to compose Workflows by combining Workflows. Each of these Workflows and their combinations may have its own (different) Anchor. Each Anchor will completely own its Workflow, and a higher level Anchor can own a Workflow combination. For example, a customer may create a complex service by combining Workflows in a private cloud and a public cloud through a single request. Or, one provider may create services in their network and another provider's network through the same request. Or, a single request may be orchestrated by multiple domain-specific proxies within a provider's network. To distribute Workflows across service domains and provider/customer boundaries, a large Workflow may be decomposed into individual Workflows owned by individual Proxies. Workflow-M +---------+ +--------------| Proxy-B | Workflow | +---------+ MN | | | | V V | Execute +---------+ | Workflow-M | Proxy-A |---+ Workflow-Y +---------+ +---------+ | +------------| Proxy-D | | Execute | +---------+ | Workflow-X | | | ^ | V | | | Execute | Workflow-N +---------+ | Workflow-Y +--------------| Proxy-C |----+ +---------+ | Execute | Workflow-Z | ^ | | | Workflow-Z +---------+ +------------| Proxy-E | +---------+ Figure-9: Distributing Workflows In Figure-8, a workflow branching is illustrated. Proxy-A receives a two-stage workflow called MN (M and N are two stages) and forwards it to Proxies B and C. Proxy B executes the Workflow M as is. The Proxy C divides the Workflow N into Workflows X, Y and Z. Proxy C executes Dalela Expires July 4, 2012 [Page 18] Internet-Draft SOP Network Architecture January 2012 the workflow X by itself, and delegates Y and Z to other proxies D and E. Workflow division allows intelligence related to a Workflow to be abstracted. The implementation of a Workflow may be changed while keeping the interface to it unchanged. The mapping between Workflows and their branching patterns may also be changed. This gives operators flexibility in how they want to deploy services. 7. Security Considerations Encryption and authentication of SOP messages is described in the Protocol document [SOP]. The LP is responsible for securing a Provider's network. The LP and RP should establish secure connections over IPSec or other kinds of VPNs over the Internet. 8. IANA Considerations NA. 9. Conclusions This document described the architecture for separating service- independent and service-dependant orchestration functions at the network level. This architecture can be used to rapidly create new services and for security and policy control of service networks. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.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 [XSD] XML Schema Description http://www.w3.org/XML/Schema [OCL] Object Constraint Language http://www.omg.org/technology/documents/modeling_spec_catal og.htm#OCL Dalela Expires July 4, 2012 [Page 19] Internet-Draft SOP Network Architecture January 2012 11. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Dalela Expires July 4, 2012 [Page 20] Internet-Draft SOP Network Architecture 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 21]