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

                    Service Description Framework (SDF)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Dalela                   Expires July 4, 2012                  [Page 1]

Internet-Draft      Service Description Framework          January 2012


   Cloud services need to interoperate across providers, vendors and
   private/public domains. To enable this interoperability, there should
   be a standard way to exchange service information. The purpose of
   this document is to detail different kinds of information necessary
   to describe services. We identify the following kinds of service-
   dependant information needed for any kind of service:

   -  Method for naming services and identifying service classes.

   -  Method for describing syntax for properties of service classes.

   -  Method for defining semantics in a service class, by establishing
     rules about relations between various service classes.

   -  Method to define Tasks and Workflows for orchestration by bundling
     services from one or more service classes.

   The collection of the above is called the Service Description
   Framework (SDF). SDF payloads can be carried inside Service
   Orchestration Protocol (SOP) packets as content. While SOP carries
   service-independent information, service-dependant information is
   attached as a SDF payload to SOP packets. This is similar to how HTML
   is sent using HTTP, or SDP carried in SIP packets.

   To construct SDF payloads, a language is required to construct
   service-dependant information. We choose XML as the basic tool to
   construct SDF payloads given that XML already has the technologies to
   specify the syntax and semantics in any vocabulary. Except for
   service names, which are described in dotted-decimal notation,
   syntax, semantics and workflows are described in XML.

   We also describe a simplified Service Workflow Description Language
   (SWDL) that maps all Tasks in a Workflow to messages in SOP. This
   makes any SDF Workflow easily executed by a SOP Proxy.

Table of Contents

   1. Introduction...................................................4
   2. Conventions used in this document..............................5
   3. Terms and Acronyms.............................................5
   4. Problem Statement..............................................6
      4.1. Naming Services...........................................6
      4.2. Describing Workflows......................................7
      4.3. Describing Service Syntax.................................7
      4.4. Describing Service Semantics..............................8

Dalela                   Expires July 4, 2012                  [Page 2]

Internet-Draft      Service Description Framework          January 2012

   5. Service Domain Names (SDN).....................................8
   6. Service Syntax Specification..................................10
      6.1. XML Schemas for Service Syntax...........................10
      6.2. Vendor Specific Domains (VSD)............................12
   7. Domain Semantics Rules (DSR)..................................12
   8. Service Workflows Description Language (SWDL).................14
   9. Formal Syntax.................................................14
   10. Security Considerations......................................16
   11. IANA Considerations..........................................16
   12. Conclusions..................................................16
   13. References...................................................17
      13.1. Normative References....................................17
      13.2. Informative References..................................17
   14. Acknowledgments..............................................18
   Appendix A. Example XML Schemas..................................19
      A.1. Example XML Schema for SDN..................19
      A.2. Example XML Schema for SDN..........19

Dalela                   Expires July 4, 2012                  [Page 3]

Internet-Draft      Service Description Framework          January 2012

1. Introduction

   This document describes a framework for describing services. This
   framework is called the Service Description Framework (SDF). SDF
   payloads can be sent as content in Service Orchestration Protocol
   [SOP] packets. SOP and SDF are service-independent and service-
   dependant components of a service orchestration request respectively.
   The relation between SOP and SDF is similar to that between SIP and
   SDP, HTTP and HTML or SMTP and MIME. Separation of service-
   independent and service-dependant components in a service request
   makes this mechanism easily extensible for any service type.

   Requirements for SOP and SDF are described in [REQT]. Network
   architecture for deploying SOP/SDF based services is described in
   [ARCH]. A detailed protocol description of SOP is present in [SOP].
   This document covers SDF and how its components can be implemented.

   SDF is comprised of the following components:

   -  A standard naming convention for naming services. To exchange
     service information, we must know the entity to which the
     information pertains. This requires a naming convention. Like
     other kinds of names in the Internet (IP and DNS), service names
     can also be hierarchical. We describe a service naming scheme
     called a Service Domain Name (SDN) in this document.

   -  A method to validate the syntax in which a service domain is
     described. We propose the use of XML to define a service domain's
     attributes. Thereafter, XML schemas can be used to define the
     syntax of each domain. Service requests for that type of service
     MUST conform to the XML schema defined for that domain.

   -  A method to define service semantics. When stitching services
     together, the key problem is to ensure that independently created
     services work seamlessly together. To make this work, inter-
     service relations must be specified. The rules for these relations
     can be specified using XML technologies, such that all instances
     of different types of services that conform to those rules will
     work seamlessly as if they were a single coherent service.

   -  A standard schema for defining workflows. To orchestrate complex
     services, an orchestrator needs to follow a well-defined
     procedure. Some steps in this procedure may be sequential, while
     others are parallel. There may be a close dependency in some tasks
     being completed successfully before others are initiated.
     Orchestration procedures must map to Tasks that a SOP Proxy can

Dalela                   Expires July 4, 2012                  [Page 4]

Internet-Draft      Service Description Framework          January 2012

     execute. Therefore, we define a Workflow language whose Tasks are
     mapped to message types in SOP. Accordingly, we define a Service
     Workflow Description Language (SWDL) that maps Workflows to SOP
     messages that a SOP Proxy can transmit or receive.

   This document does not provide any service-domain specific
   definitions. Service-specific attribute definitions need to be done,
   but that is outside scope of present document.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3. Terms and Acronyms

   The key words Provider, Vendor, User, Orchestration, Client, in this
   document have the same meaning as defined in SOP requirements [REQT].

   The key words Proxy, Workflow Server (WS), Service Node (SN) in the
   document have the same meaning as defined in SOP architecture [ARCH].

   Service Description Framework (SDF): Framework to describe service
   dependant attributes (SOP is service-independent). The relation
   between SOP and SDF is similar to that between SIP and SDP, HTTP and
   HTML, or SMTP and MIME. SOP, similar to SIP/HTTP/SMTP represents the
   content independent control plane. SDF, similar to SDP, HTML and
   MIME, represents the service-dependant content.

   Service Domain Name (SDN): A SDN identifies a logically cohesive set
   of services. SDNs can be defined hierarchically and a SDN is labeled
   by a dotted decimal name similar to DNS names.

   SDN Attributes: Every SDN is associated with a set of attributes
   using which a service can be described. These attributes may be
   represented through XML, text, binary, or other kinds of formats.
   Attributes of the parent SDN may be inherited into the child SDN, or
   they could be overridden in the child SDN.

   Vendor Specific Domain (VSD): A vendor may choose to define some
   private domains that are understood only by services supplied by that
   vendor. Vendor specific domains consist of service-dependant

Dalela                   Expires July 4, 2012                  [Page 5]

Internet-Draft      Service Description Framework          January 2012

   attributes that are not part of any SDN. VSDs allow a vendor to
   include parameters that only their implementation understands. As far
   as possible, VSDs should be avoided to maintain interoperability.
   However in some cases, they may be needed.

   Service Workflow Description Language (SWDL): An XML language to
   describe workflows. A workflow is an ordered collection of tasks that
   have been sequenced or parallelized. The Tasks in SWDL are operations
   that a SOP Proxy can perform. That is, the tasks are mapped directly
   to SOP messages. To execute a Task in SWDL, the SOP Proxy has to send
   or receive a message as indicated by the SWDL.

   Hierarchical Services Description (HSD): This refers to a practice of
   defining service hierarchically by inheriting the parent domain's
   attributes into the child domains. XML already supports the ability
   to inherit elements from one schema into another. XML also supports
   the ability to override those elements in a domain-specific way.

   Domain Semantics Rules (DSR). This refers to relations between the
   terms in one domain's vocabulary and terms of other domains. These
   relations give meanings to terms in a vocabulary.

4. Problem Statement

4.1. Naming Services

   For network elements to exchange service information there has to be
   a standard way to refer to services. For example, if a provider rents
   out virtual machines and a user wants to rent virtual machines, a
   common naming convention to refer to the virtual machine service is
   needed. With a standard naming convention, consumers and providers
   can learn about service requirements and availability.

   A standard naming convention for services does not exist today. In
   the Internet there are two kinds of names - (a) the Domain Name and
   (b) the IP Address. Both these names identify specific hardware or
   software entities but not "types" or "classes" of devices. A virtual
   machine is for example a class of service. When a provider
   advertizes, or a customer requests, a virtual machine, they are not
   going to refer to it by a DN or IP. They need to refer to the virtual
   machine in another way because the machine may yet to be instantiated
   and hence will not have a valid DN or IP address.

   Both DNS and IP are "proper nouns" and they identify specific
   instances of services. Service advertisement and discovery requires
   "common nouns". It should be possible to aggregate services during

Dalela                   Expires July 4, 2012                  [Page 6]

Internet-Draft      Service Description Framework          January 2012

   advertisement which is possible if service names are hierarchical. We
   will call this naming convention Service Domain Names (SDN).

4.2. Describing Workflows

   A complex service orchestration requires executing multiple Tasks in
   a specific order. Some of these Tasks may be sequential, some others
   in parallel. Some Tasks may be bundled together and these bundles may
   be sequenced or parallelized. The exact order of Task execution will
   depend on specific types of services, and how these are customized
   for users. A standard language to describe Task ordering is needed.

   We will call this scheme of ordering Tasks, the Service Workflow
   Description Language (SWDL), which is an XML schema used to describe
   Workflows. It is enough for this scheme to be customized to describe
   Tasks for SOP. Tasks in SWDL should map to one of the SOP messages,
   so that a SOP Proxy can execute them. The execution of these tasks
   requires a SOP Proxy to transmit or receive these messages.

4.3. Describing Service Syntax

   Service descriptions have to have definite syntax and semantics. If
   services are described in XML, syntax validation can be performed by
   specifying a domain-specific XML schema.

   Since SDNs are hierarchical, it is possible to apply object-oriented
   concepts to the attributes of each SDN. For instance, it is now
   conceivable that attributes of a parent service domain are available
   in a child service domain. All properties of compute domain are can
   be inherited in the virtual compute domain, and some attributes may
   be overridden within the virtual compute domain.

   The ability to use hierarchy concepts in service domains can be a
   huge advantage if we describe a mechanism by which one domain can
   inherit another domain and how attributes of one service domain may
   be inherited by another service domain. We call this mechanism of
   inheriting service attributes Hierarchical Services Description
   (HSD). Use of HSD allows a vendor or provider to rapidly develop new
   services, by inheriting the attributes of other service domains. A
   few attributes may need to be added or overridden.

   A SDN may inherit attributes of one or more domains. For instance,
   "routing" and "switching" domains may inherit the "network" domain
   and a "virtual firewall" domain will inherit both the "firewall" and
   "virtual machine" domains. By inheriting domains large portions of a
   domain's attributes can be automatically re-used.

Dalela                   Expires July 4, 2012                  [Page 7]

Internet-Draft      Service Description Framework          January 2012

4.4. Describing Service Semantics

   The problem of semantics involves two kinds of issues: (a) map a term
   in the description to a physical/logical/virtual resource, and (b)
   relate terms across multiple domains to have the same meaning (they
   pertain to the same resource). An example of the first issue is that
   a term like "mac-address" may refer to the MAC address of a VM. An
   example of the second issue is that "mac-addr", "mac-address" and
   "macaddr" may all refer to the same MAC address in different domains.
   These terms may be buried under different layers of hierarchy.

   The first problem can be solved if the resource advertisement and
   resource request use the same vocabulary. The name to resource
   mapping is then solved because the resources advertised and the
   resources requested are called by the same name. The second problem
   can be solved if we establish relations between terms of vocabularies
   across different domains. These relations need to be honored during
   resource allocation to make services that are orchestrated across
   multiple domains to work seamlessly.

5. Service Domain Names (SDN)

   To interoperate services, there is need for a common way to refer to
   services. In other words, there has to be a way to "name" services.
   This naming should be hierarchical, as that makes it easy to identify
   classes of service. To facilitate service classification, we can
   define SDN using a dotted decimal notation, in a similar way as host
   Domain Names and IP addresses have been assigned so far.

   The DNS system keeps the root of the name towards the right-end of
   the name. The IP naming system keeps the network/subnet part of the
   address toward the left-end of the address. The SNMP OID scheme uses
   the left-to-right naming scheme. Both ways of naming have been
   equally popular and we just have to choose one of them.

   We chose the left-to-right naming scheme for naming services. Using
   this convention a domain a.b.c will mean that "a" is the root SDN;
   that "b" is the child domain of "a", and "c" is the child domain of
   "b". The naming convention can be made into a tree with the left-most
   node being the root and the right-most nodes being the leaves.

   An example tree of services is Figure-1. This Figure should be
   regarded illustrative only, and meant to describe the concept of
   hierarchical SDNs. A sufficiently comprehensive description of
   service hierarchies is deferred to a later document.

Dalela                   Expires July 4, 2012                  [Page 8]

Internet-Draft      Service Description Framework          January 2012

                              | services |
             |                      |                      |
         +------+               +------+               +------+
         | iaas |               | paas |               | saas |
         +------+               +------+               +------+
             |                      |                      |
    +--------+                    . . .                  . . .
    |   +---------+
    +---| compute |
    |   +---------+
    |   +---------+
    +---| storage |
    |   +---------+
    |   +---------+
    +---| network |---+
        +---------+   |
                      |   +-----------+
                      +---| switching |
                      |   +-----------+
                      |   +-----------+
                      +---| routing   |
                      |   +-----------+
                      |   +-----------+
                      +---| transport |
                      |   +-----------+
                      |   +-----------+
                          +-----------+  |  +----------+
                                         +--| dpi      |
                                         |  +----------+
                                         |  +----------+
                                         +--| firewall |
                                         |  +----------+
                                         |  +----------+
                                         +--| waas     |
                                         |  +----------+
                                         |  +----------+
                                         +--| vpn      |

                       Figure-1 Service Domain Names

Dalela                   Expires July 4, 2012                  [Page 9]

Internet-Draft      Service Description Framework          January 2012

   Using this kind of domain naming convention, we can define domains
   like, or

6. Service Syntax Specification

   Once Service Domain Names are defined, each domain must have an
   associated set of attributes, which collectively define the "syntax"
   through which that domain is defined. An abstract language is
   required to define domain attributes, and we recommend use of XML to
   define all XML attributes.

6.1. XML Schemas for Service Syntax

   The syntax of each XML defined service domain can be defined through
   an XML schema, within which we define domain elements and attributes.
   Since the SDNs form a hierarchy, it is easy to inherit one domain's
   attributes into another. XML inherit mechanisms can be used to
   inherit one domain's attributes into another.

   By using hierarchical XML schemes and inheriting namespaces, the
   functionality that has been built for one domain can be easily re-
   used by the inheriting domain. A new service definition only needs to
   define what it has added or modified on top of the existing domains.
   This will simplify the creation of new services, in a manner
   analogous to how object-oriented design (object inheritance) greatly
   improves code-reuse and accelerates application development.

   Appendix A describes example XML schemas for domains and The first defines an element "hub" while the
   second defines an element "router". The "router" element inherits
   attributes from the schema, by adding an "ip-address"
   and "subnet-mask" elements to it. These schemas can be used to
   construct SDF payloads for a hub and router. This is shown below.

   ------------------ Example: SDF payload for a HUB ------------------

      <?xml version="1.0" ?>
      <domain name="" type="capability" def="sdn">
        <d1:hub xmlns:xsi=""
         xsi:schemaLocation=" iaas.compute.xsd">
          < d1:interface>

Dalela                   Expires July 4, 2012                 [Page 10]

Internet-Draft      Service Description Framework          January 2012



   ----------------- Example: SDF payload for a ROUTER ----------------

      <?xml version="1.0" ?>
      <domain name="" type="capability" def="sdn">
        <d1:router xmlns:xsi=""
         xsi:schemaLocation=" iaas.compute.routing.xsd">


   The <domain> XML element is used to encapsulate the domain-specific
   service description in a standard way that the receiver can
   interpret. This element has the following attributes:

   -  A Domain Name Attribute - this is the SDN for payload contained
     within the <domain> tag. It helps the receiver identify the SDN
     and determine if the receiver knows how to deal with the payload.

   -  A Type Attribute - this has two possible values: "capability" and
     "availability". The "capability" attribute is used in requesting
     actions by the receiver. The "availability" attribute is used by
     the service to advertize its service availabilities. With

Dalela                   Expires July 4, 2012                 [Page 11]

Internet-Draft      Service Description Framework          January 2012

     virtualized services, the availability reduces as services are
     allocated to users, although the capability remains unchanged. The
     capability would however change in case of partial or total
     service failures, such as software or hardware failures.

   -  The Def Attribute - this allows standard and non-standard payloads
     to be sent in the same manner. For standard domains, the attribute
     has the value "sdn" and for non-standard domains the attribute is
     set to "vsd". Non-standard domains are defined in Section 6.2.

   The domain scheme described here can be used in conjunction with
   existing standard or non-standard service definitions. For instance,
   the domain scheme may be used in conjunction with an existing
   specification such as OVF [OVF] or others to be defined. The OVF
   scheme will need to be identified by a SDN, such as
   iaas.compute.virtual. This is shown below.

      <domain name="iaas.compute.virtual" type="capability" def="sdn">
         <!-- list of OVF elements and attributes -->

6.2. Vendor Specific Domains (VSD)

   There may be a need for vendors to deliver service customizations
   that are non-standard or pre-standard. Such services may be defined
   in exactly the same manner as standard service definitions. To
   describe the fact that this is a vendor specific domain, and may not
   be understood by every network element, the domain has to be (a)
   given a name that does not overlap with standard domain names, and
   (b) identified by the def="vsd" attribute in the <domain> element.

   For example, a "vendor" may define their private domain
   "vendor.router" and this domain would be referred to as follows.

      <domain name="vendor.router" type="capability" def="vsd">
         <!-- list of vendor-specific elements and attributes -->

   Vendor defined domains MUST begin with the vendor's name. VSDs may be
   treated differently in how they are used across boundaries. For
   instance, a customer might advertize VSDs to selected customers.

7. Domain Semantics Rules (DSR)

   XML schemas associated with domains define the elements, their
   attributes and the syntax for describing a elements and attributes.

Dalela                   Expires July 4, 2012                 [Page 12]

Internet-Draft      Service Description Framework          January 2012

   The XML schema does not give us the semantics of a domain's elements
   and attributes. This gap has to be filled up in other ways.

   What is domain semantics? Domain semantics is the relation between
   attributes within and across domains. This relation is seen in how
   resources (logical, virtual or physical) are allocated to populate
   elements and attributes in XML documents in a coordinated fashion.

   For example, the MAC address assigned to a VM must be unique amongst
   the hosts that the VM is going to interact with. This uniqueness is a
   relation between the various MAC addresses. Then, the MAC address on
   the VM must also be in access-lists on the network. This is a
   relation between the compute and network domains. The network based
   storage must be mapped to file systems on the host, requiring a
   mapping of logical and virtual resources across compute and storage
   domains. To restrict access to the storage to certain hosts, there
   has to be a relation between host, network and storage domains.

   Relations between attributes within and across domains constrain
   resource allocation. When resources are allocated according to these
   constraints, services created across different domains work together
   seamlessly in the intended way. Domain semantics is the relation
   between attributes within a domain and across domains.

   Therefore, after we have XML schemas for each domain with the ability
   to inherit domains, there is still a need to express the relations
   between attributes. Again, this is easily achieved if the domain
   schema is expressed in a high-level language such as XML. XML
   technologies such as Object Constraint Language [OCL] and Schematron
   [STRON] can be used to describe semantic relations. An example
   constraint is shown below where the VLAN configured on a VM interface
   is equal to the VLAN access allowed on the network switch.

     /[0]/acl@vlan =

   Semantic rules that specify relations between domain attributes
   SHOULD be defined in separate Domain Semantics Rules (DSR) files.
   Each DSR file may be associated with a Workflow, as the rules are
   often likely to be user or service specific. Similar to hierarchical
   domain specifications, it is also possible to define parent and child
   DSR files. Specification of semantics through DSR files, allows a
   service to be rapidly customized, and new services to be created.

   A reusable hierarchy of DSR files MAY be defined to facilitate
   service relations across domains. Specification of this hierarchy is
   left to a later effort and contributions are welcome.

Dalela                   Expires July 4, 2012                 [Page 13]

Internet-Draft      Service Description Framework          January 2012

8. Service Workflows Description Language (SWDL)

   Workflows are needed to group tasks sequentially or in parallel. Such
   grouping may bundle domain names and may involve many target devices.
   For instance, it may be necessary to treat the creation of a virtual
   machine and its associated network configuration as a single task
   group. Failure of one of the tasks in this group may result in the
   reversal of the entire task group.

   To construct a flowchart using tasks, task groups, and workflows, we
   need to (a) label individual items in the workflow, and (b) order the
   items using "prev" and "next" tags. Each Workflow MUST have an
   associated Workflow Anchor (WA). The WA is the controller of the
   Workflow and the only one authorized to execute the Workflow. The
   Anchor attribute MAY have more than one Proxy to execute it.

   The following XML captures these requirements.

     <workflow name="X32mnTrUwq" id="k9DjR5lbcw"
          xmlns:sdf="" anchor="">

       <description>workflow description</description>
       <taskgroup id="1" prev="idle" next="idle">
          <description>taskgroup description</description>
          <task id="1" prev="idle" next="idle"
              server="" type="CREATE">
            <domain name="..." type="capability">
              <!-- list of domain attributes -->

   The XML schema for Workflows and Tasks is defined in Section 9. The
   "type" of each Task must map to one of the messages in SOP. Sending
   and receiving those messages can be expected of a SOP Proxy. The
   attribute of "server" defines the network element that will process
   the task or workflow. The "server" could be a SN, Proxy, WS, etc. The
   "instance" attribute in the workflow identifies an instance of a
   Workflow. It MUST be set equal to the Exchange header value in the
   SOP message (this relates SOP messages with SDF content).

9. Formal Syntax

   The XML schema for SDF is given below. This is an initial attempt and
   likely to evolve with inputs. Contributions are welcome here.

Dalela                   Expires July 4, 2012                 [Page 14]

Internet-Draft      Service Description Framework          January 2012

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs=""
       xmlns="" elementFormDefault="qualified">

      <xs:element name="domain" type="xs:string">
        <xs:attribute name="name" type="xs:string"/>
        <xs:attribute name="def">
            <xs:restriction base="xs:string">
              <xs:enumeration value="sdn"/>
              <xs:enumeration value="vsd"/>
        <xs:attribute name="type">
            <xs:restriction base="xs:string">
              <xs:enumeration value="capability"/>
              <xs:enumeration value="availability"/>

      <xs:element name="workflow" >
        <xs:attribute name="name" type="xs:string" use="required"/>
        <xs:attribute name="anchor" type="xs:string"/>
        <xs:attribute name="id" type="xs:string"/>
        <xs:attribute name="distance" type="xs:integer"/>
          <xs:element name="description" type="xs:string"/>
          <xs:element name="taskgroup" maxOccurs="unbounded">
            <xs:attribute name="id" type="xs:string"/>
            <xs:attribute name="prev" type="xs:string"/>
            <xs:attribute name="next" type="xs:string"/>
              <xs:element name="description" type="xs:string"/>
              <xs:element name="task" maxOccurs="unbounded">
                <xs:attribute name="id" type="xs:string"/>
                <xs:attribute name="prev" type="xs:string"/>
                <xs:attribute name="next" type="xs:string"/>
                <xs:attribute name="server" type="xs:string"/>
                <xs:attribute name="status" type="xs:string">
                    <xs:restriction base="xs:string">
                      <xs:enumeration value="pending"/>

Dalela                   Expires July 4, 2012                 [Page 15]

Internet-Draft      Service Description Framework          January 2012

                      <xs:enumeration value="complete"/>
                <xs:attribute name="reference" type="xs:integer"/>
                <xs:attribute name="action">
                    <xs:restriction base="xs:string">
                      <xs:enumeration value="CREATE"/>
                      <xs:enumeration value="DELETE"/>
                      <xs:enumeration value="TRANSFER"/>
                      <xs:enumeration value="GET"/>
                      <xs:enumeration value="UPDATE"/>
                      <xs:enumeration value="WORKFLOW"/>
                      <xs:enumeration value="COMMIT"/>
                      <xs:enumeration value="CANCEL"/>
                <xs:element type="domain"/>

10. Security Considerations

   Validation of SDF payloads is defined in the SOP Architecture [ARCH].
   Security aspects of SDF are covered in the SOP document [SOP].

11. IANA Considerations


12. Conclusions

   SDF specifies four kinds of information needed to describe services.
   This information can be transported as content of SOP messages. We
   use XML technologies and their capabilities to represent a service
   domain's syntax and semantics. Use of SDF has following benefits:

   -  Relation between service domains (Domain Hierarchy). The SDN
     convention allows multiple service "domains" to be defined, and
     the relation between these domains, by inheriting other domains.
     Advantages of this approach can be likened to benefits from

Dalela                   Expires July 4, 2012                 [Page 16]

Internet-Draft      Service Description Framework          January 2012

     object-oriented software, where new objects can be developed by
     reusing functionality in existing objects.

   -  Domain syntax validation (Service Schema). This helps define the
     format in which service requests/updates must be made and
     mechanism to validate a request/update syntax.

   -  Domain semantics for resource allocation (Relational Rules). This
     helps relate resources in one service domain to resources in other
     service domains to make them work coherently and seamlessly.

   -  Workflow description (Service Workflow Description Language). This
     helps define different task groupings and task order that may use
     one or more service domains, to orchestrate a complex service.

13. References

13.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2. Informative References

   [NIST] DRAFT Cloud Computing Synopsis and Recommendations

   [REQT] Service Orchestration Protocol Requirements

   [ARCH] Service Orchestration Protocol Network Architecture

   [SOP] Service Orchestration Protocol

   [OVF] Open Virtualization Format

   [XSD] XML Schema Description

   [OCL] Object Constraint Language

Dalela                   Expires July 4, 2012                 [Page 17]

Internet-Draft      Service Description Framework          January 2012

   [STRON] Schematron Specification

14. Acknowledgments

   This document was prepared using

Dalela                   Expires July 4, 2012                 [Page 18]

Internet-Draft      Service Description Framework          January 2012

Appendix A.                 Example XML Schemas

   This Appendix illustrates the use of XML schemas for designing
   hierarchical service domains. Appendix A.1. gives an example schema
   for the domain, eventually defining a "hub". Appendix
   A.2. shows how the schema can be extended to define a schema, eventually defining a "router".

A.1. Example XML Schema for SDN

   This schema defines the "interface" element and a "hub" element as
   collection "interface" elements.

   ----------------------- ---------------------

   <?xml version="1.0"?>
   <xs:schema xmlns:xs=""

     <xs:element name="hub" type=""/>

     <xs:simpleType name="intf-type">
       <xs:restriction base="xs:string">
         <xs:enumeration value="Ethernet" />
         <xs:enumeration value="GigabitEthernet" />

     <xs:complexType name="interface">
         <xs:element name="intf-type" type="intf-type"/>
         <xs:element name="module" type="xs:string"/>
         <xs:element name="intf-num" type="xs:string"/>

     <xs:complexType name="">
       <xs:element name="interface" type="interface" minOccurs="0"/>


A.2. Example XML Schema for SDN

   This schema inherits the schema from It adds the
   elements "ip-address" and "subnet-mask" to the "interface" creating

Dalela                   Expires July 4, 2012                 [Page 19]

Internet-Draft      Service Description Framework          January 2012

   L3 interfaces. A collection of such interfaces can now form a
   "router" element.

   ------------------- -----------------

   <?xml version="1.0" ?>
   <xs:schema xmlns:xs=""

     <xs:include schemaLocation=""/>
     <xs:element name="router" type=""/>

     <xs:complexType name="l3-interface">
         <xs:extension base="interface">
           <xs:element name="ip-address" type="xs:string"/>
           <xs:element name="subnet-mask" type="xs:string"/>

     <xs:complexType name="">
       <xs:element name="interface" type="l3-interface" minOccurs="0"/>


Dalela                   Expires July 4, 2012                 [Page 20]

Internet-Draft      Service Description Framework          January 2012

   Authors' Addresses

   Ashish Dalela
   Cisco Systems
   Cessna Business Park
   India 560037


   Mike Hammer
   USA 20190


   Monique Morrow
   Cisco Systems [Switzerland] GmbH
   Richistrasse 7


   Peter Tomsu
   Cisco Systems Austria GmbH
   30 Floor, Millennium Tower
   Handelskai 94-96
   A-1200   Vienna


Dalela                   Expires July 4, 2012                 [Page 21]