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

Versions: 00

Network Working Group                                         A. Dalela
Internet Draft                                            Cisco Systems
Intended status: Standards Track                              M. Hammer
Expires: July 2012                                      January 4, 2012



                         SOP 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]


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