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) draft-dalela-sdf-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 4, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Dalela Expires July 4, 2012 [Page 1] Internet-Draft Service Description Framework January 2012 Abstract 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 iaas.network SDN..................19 A.2. Example XML Schema for iaas.network.routing 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Terms and Acronyms The key words Provider, Vendor, User, Orchestration, Client, in this document have the same meaning as defined in SOP requirements [REQT]. The key words Proxy, Workflow Server (WS), Service Node (SN) in 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 | | +-----------+ | +-----------+ +---|application|--+ +-----------+ | +----------+ +--| 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 iaas.network.switching, or iaas.network.security. 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 iaas.network and iaas.network.routing. The first defines an element "hub" while the second defines an element "router". The "router" element inherits attributes from the iaas.network 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 ------------------ Ethernet 1 1 < d1:interface> Dalela Expires July 4, 2012 [Page 10] Internet-Draft Service Description Framework January 2012 Ethernet 1 2 -------------------------------------------------------------------- ----------------- Example: SDF payload for a ROUTER ---------------- Ethernet 1 1 10.10.10.1 255.255.255.0 Ethernet 1 2 10.10.10.2 255.255.255.0 -------------------------------------------------------------------- The 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 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. 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 element. For example, a "vendor" may define their private domain "vendor.router" and this domain would be referred to as follows. 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. /iaas.network.switching/port-list[0]/acl@vlan = /iaas.compute/vm-list[0]/interface-list[0]/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 description taskgroup description 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 Dalela Expires July 4, 2012 [Page 15] Internet-Draft Service Description Framework January 2012 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 NA 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 http://csrc.nist.gov/publications/drafts/800-146/Draft- NIST-SP800-146.pdf [REQT] Service Orchestration Protocol Requirements http://www.ietf.org/id/draft-dalela-orchestration-00.txt [ARCH] Service Orchestration Protocol Network Architecture http://www.ietf.org/id/draft-dalela-sop-architecture-00.txt [SOP] Service Orchestration Protocol http://www.ietf.org/id/draft-dalela-sop-00.txt [OVF] Open Virtualization Format http://xml.coverpages.org/DMTF-OVF-v10-DSP0243.pdf [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 17] Internet-Draft Service Description Framework January 2012 [STRON] Schematron Specification http://www.schematron.com/spec.html 14. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 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 iaas.network domain, eventually defining a "hub". Appendix A.2. shows how the iaas.network schema can be extended to define a iaas.network.routing schema, eventually defining a "router". A.1. Example XML Schema for iaas.network SDN This schema defines the "interface" element and a "hub" element as collection "interface" elements. ----------------------- file:iaas.network.xsd --------------------- ------------------------------------------------------------------- A.2. Example XML Schema for iaas.network.routing SDN This schema inherits the schema from iaas.network. 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. ------------------- file:iaas.network.routing.xsd ----------------- ------------------------------------------------------------------- Dalela Expires July 4, 2012 [Page 20] Internet-Draft Service Description Framework 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]