idnits 2.17.1 draft-dalela-sdf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2012) is 4497 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Switzerland' is mentioned on line 865, but not defined == Unused Reference: 'NIST' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'XSD' is defined on line 759, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Dalela 2 Internet Draft Cisco Systems 3 Intended status: Standards Track M. Hammer 4 Expires: July 2012 January 4, 2012 6 Service Description Framework (SDF) 7 draft-dalela-sdf-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on July 4, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Abstract 46 Cloud services need to interoperate across providers, vendors and 47 private/public domains. To enable this interoperability, there should 48 be a standard way to exchange service information. The purpose of 49 this document is to detail different kinds of information necessary 50 to describe services. We identify the following kinds of service- 51 dependant information needed for any kind of service: 53 - Method for naming services and identifying service classes. 55 - Method for describing syntax for properties of service classes. 57 - Method for defining semantics in a service class, by establishing 58 rules about relations between various service classes. 60 - Method to define Tasks and Workflows for orchestration by bundling 61 services from one or more service classes. 63 The collection of the above is called the Service Description 64 Framework (SDF). SDF payloads can be carried inside Service 65 Orchestration Protocol (SOP) packets as content. While SOP carries 66 service-independent information, service-dependant information is 67 attached as a SDF payload to SOP packets. This is similar to how HTML 68 is sent using HTTP, or SDP carried in SIP packets. 70 To construct SDF payloads, a language is required to construct 71 service-dependant information. We choose XML as the basic tool to 72 construct SDF payloads given that XML already has the technologies to 73 specify the syntax and semantics in any vocabulary. Except for 74 service names, which are described in dotted-decimal notation, 75 syntax, semantics and workflows are described in XML. 77 We also describe a simplified Service Workflow Description Language 78 (SWDL) that maps all Tasks in a Workflow to messages in SOP. This 79 makes any SDF Workflow easily executed by a SOP Proxy. 81 Table of Contents 83 1. Introduction...................................................4 84 2. Conventions used in this document..............................5 85 3. Terms and Acronyms.............................................5 86 4. Problem Statement..............................................6 87 4.1. Naming Services...........................................6 88 4.2. Describing Workflows......................................7 89 4.3. Describing Service Syntax.................................7 90 4.4. Describing Service Semantics..............................8 92 5. Service Domain Names (SDN).....................................8 93 6. Service Syntax Specification..................................10 94 6.1. XML Schemas for Service Syntax...........................10 95 6.2. Vendor Specific Domains (VSD)............................12 96 7. Domain Semantics Rules (DSR)..................................12 97 8. Service Workflows Description Language (SWDL).................14 98 9. Formal Syntax.................................................14 99 10. Security Considerations......................................16 100 11. IANA Considerations..........................................16 101 12. Conclusions..................................................16 102 13. References...................................................17 103 13.1. Normative References....................................17 104 13.2. Informative References..................................17 105 14. Acknowledgments..............................................18 106 Appendix A. Example XML Schemas..................................19 107 A.1. Example XML Schema for iaas.network SDN..................19 108 A.2. Example XML Schema for iaas.network.routing SDN..........19 110 1. Introduction 112 This document describes a framework for describing services. This 113 framework is called the Service Description Framework (SDF). SDF 114 payloads can be sent as content in Service Orchestration Protocol 115 [SOP] packets. SOP and SDF are service-independent and service- 116 dependant components of a service orchestration request respectively. 117 The relation between SOP and SDF is similar to that between SIP and 118 SDP, HTTP and HTML or SMTP and MIME. Separation of service- 119 independent and service-dependant components in a service request 120 makes this mechanism easily extensible for any service type. 122 Requirements for SOP and SDF are described in [REQT]. Network 123 architecture for deploying SOP/SDF based services is described in 124 [ARCH]. A detailed protocol description of SOP is present in [SOP]. 125 This document covers SDF and how its components can be implemented. 127 SDF is comprised of the following components: 129 - A standard naming convention for naming services. To exchange 130 service information, we must know the entity to which the 131 information pertains. This requires a naming convention. Like 132 other kinds of names in the Internet (IP and DNS), service names 133 can also be hierarchical. We describe a service naming scheme 134 called a Service Domain Name (SDN) in this document. 136 - A method to validate the syntax in which a service domain is 137 described. We propose the use of XML to define a service domain's 138 attributes. Thereafter, XML schemas can be used to define the 139 syntax of each domain. Service requests for that type of service 140 MUST conform to the XML schema defined for that domain. 142 - A method to define service semantics. When stitching services 143 together, the key problem is to ensure that independently created 144 services work seamlessly together. To make this work, inter- 145 service relations must be specified. The rules for these relations 146 can be specified using XML technologies, such that all instances 147 of different types of services that conform to those rules will 148 work seamlessly as if they were a single coherent service. 150 - A standard schema for defining workflows. To orchestrate complex 151 services, an orchestrator needs to follow a well-defined 152 procedure. Some steps in this procedure may be sequential, while 153 others are parallel. There may be a close dependency in some tasks 154 being completed successfully before others are initiated. 155 Orchestration procedures must map to Tasks that a SOP Proxy can 156 execute. Therefore, we define a Workflow language whose Tasks are 157 mapped to message types in SOP. Accordingly, we define a Service 158 Workflow Description Language (SWDL) that maps Workflows to SOP 159 messages that a SOP Proxy can transmit or receive. 161 This document does not provide any service-domain specific 162 definitions. Service-specific attribute definitions need to be done, 163 but that is outside scope of present document. 165 2. Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC-2119 [RFC2119]. 171 In this document, these words will appear with that interpretation 172 only when in ALL CAPS. Lower case uses of these words are not to be 173 interpreted as carrying RFC-2119 significance. 175 3. Terms and Acronyms 177 The key words Provider, Vendor, User, Orchestration, Client, in this 178 document have the same meaning as defined in SOP requirements [REQT]. 180 The key words Proxy, Workflow Server (WS), Service Node (SN) in the 181 document have the same meaning as defined in SOP architecture [ARCH]. 183 Service Description Framework (SDF): Framework to describe service 184 dependant attributes (SOP is service-independent). The relation 185 between SOP and SDF is similar to that between SIP and SDP, HTTP and 186 HTML, or SMTP and MIME. SOP, similar to SIP/HTTP/SMTP represents the 187 content independent control plane. SDF, similar to SDP, HTML and 188 MIME, represents the service-dependant content. 190 Service Domain Name (SDN): A SDN identifies a logically cohesive set 191 of services. SDNs can be defined hierarchically and a SDN is labeled 192 by a dotted decimal name similar to DNS names. 194 SDN Attributes: Every SDN is associated with a set of attributes 195 using which a service can be described. These attributes may be 196 represented through XML, text, binary, or other kinds of formats. 197 Attributes of the parent SDN may be inherited into the child SDN, or 198 they could be overridden in the child SDN. 200 Vendor Specific Domain (VSD): A vendor may choose to define some 201 private domains that are understood only by services supplied by that 202 vendor. Vendor specific domains consist of service-dependant 203 attributes that are not part of any SDN. VSDs allow a vendor to 204 include parameters that only their implementation understands. As far 205 as possible, VSDs should be avoided to maintain interoperability. 206 However in some cases, they may be needed. 208 Service Workflow Description Language (SWDL): An XML language to 209 describe workflows. A workflow is an ordered collection of tasks that 210 have been sequenced or parallelized. The Tasks in SWDL are operations 211 that a SOP Proxy can perform. That is, the tasks are mapped directly 212 to SOP messages. To execute a Task in SWDL, the SOP Proxy has to send 213 or receive a message as indicated by the SWDL. 215 Hierarchical Services Description (HSD): This refers to a practice of 216 defining service hierarchically by inheriting the parent domain's 217 attributes into the child domains. XML already supports the ability 218 to inherit elements from one schema into another. XML also supports 219 the ability to override those elements in a domain-specific way. 221 Domain Semantics Rules (DSR). This refers to relations between the 222 terms in one domain's vocabulary and terms of other domains. These 223 relations give meanings to terms in a vocabulary. 225 4. Problem Statement 227 4.1. Naming Services 229 For network elements to exchange service information there has to be 230 a standard way to refer to services. For example, if a provider rents 231 out virtual machines and a user wants to rent virtual machines, a 232 common naming convention to refer to the virtual machine service is 233 needed. With a standard naming convention, consumers and providers 234 can learn about service requirements and availability. 236 A standard naming convention for services does not exist today. In 237 the Internet there are two kinds of names - (a) the Domain Name and 238 (b) the IP Address. Both these names identify specific hardware or 239 software entities but not "types" or "classes" of devices. A virtual 240 machine is for example a class of service. When a provider 241 advertizes, or a customer requests, a virtual machine, they are not 242 going to refer to it by a DN or IP. They need to refer to the virtual 243 machine in another way because the machine may yet to be instantiated 244 and hence will not have a valid DN or IP address. 246 Both DNS and IP are "proper nouns" and they identify specific 247 instances of services. Service advertisement and discovery requires 248 "common nouns". It should be possible to aggregate services during 249 advertisement which is possible if service names are hierarchical. We 250 will call this naming convention Service Domain Names (SDN). 252 4.2. Describing Workflows 254 A complex service orchestration requires executing multiple Tasks in 255 a specific order. Some of these Tasks may be sequential, some others 256 in parallel. Some Tasks may be bundled together and these bundles may 257 be sequenced or parallelized. The exact order of Task execution will 258 depend on specific types of services, and how these are customized 259 for users. A standard language to describe Task ordering is needed. 261 We will call this scheme of ordering Tasks, the Service Workflow 262 Description Language (SWDL), which is an XML schema used to describe 263 Workflows. It is enough for this scheme to be customized to describe 264 Tasks for SOP. Tasks in SWDL should map to one of the SOP messages, 265 so that a SOP Proxy can execute them. The execution of these tasks 266 requires a SOP Proxy to transmit or receive these messages. 268 4.3. Describing Service Syntax 270 Service descriptions have to have definite syntax and semantics. If 271 services are described in XML, syntax validation can be performed by 272 specifying a domain-specific XML schema. 274 Since SDNs are hierarchical, it is possible to apply object-oriented 275 concepts to the attributes of each SDN. For instance, it is now 276 conceivable that attributes of a parent service domain are available 277 in a child service domain. All properties of compute domain are can 278 be inherited in the virtual compute domain, and some attributes may 279 be overridden within the virtual compute domain. 281 The ability to use hierarchy concepts in service domains can be a 282 huge advantage if we describe a mechanism by which one domain can 283 inherit another domain and how attributes of one service domain may 284 be inherited by another service domain. We call this mechanism of 285 inheriting service attributes Hierarchical Services Description 286 (HSD). Use of HSD allows a vendor or provider to rapidly develop new 287 services, by inheriting the attributes of other service domains. A 288 few attributes may need to be added or overridden. 290 A SDN may inherit attributes of one or more domains. For instance, 291 "routing" and "switching" domains may inherit the "network" domain 292 and a "virtual firewall" domain will inherit both the "firewall" and 293 "virtual machine" domains. By inheriting domains large portions of a 294 domain's attributes can be automatically re-used. 296 4.4. Describing Service Semantics 298 The problem of semantics involves two kinds of issues: (a) map a term 299 in the description to a physical/logical/virtual resource, and (b) 300 relate terms across multiple domains to have the same meaning (they 301 pertain to the same resource). An example of the first issue is that 302 a term like "mac-address" may refer to the MAC address of a VM. An 303 example of the second issue is that "mac-addr", "mac-address" and 304 "macaddr" may all refer to the same MAC address in different domains. 305 These terms may be buried under different layers of hierarchy. 307 The first problem can be solved if the resource advertisement and 308 resource request use the same vocabulary. The name to resource 309 mapping is then solved because the resources advertised and the 310 resources requested are called by the same name. The second problem 311 can be solved if we establish relations between terms of vocabularies 312 across different domains. These relations need to be honored during 313 resource allocation to make services that are orchestrated across 314 multiple domains to work seamlessly. 316 5. Service Domain Names (SDN) 318 To interoperate services, there is need for a common way to refer to 319 services. In other words, there has to be a way to "name" services. 320 This naming should be hierarchical, as that makes it easy to identify 321 classes of service. To facilitate service classification, we can 322 define SDN using a dotted decimal notation, in a similar way as host 323 Domain Names and IP addresses have been assigned so far. 325 The DNS system keeps the root of the name towards the right-end of 326 the name. The IP naming system keeps the network/subnet part of the 327 address toward the left-end of the address. The SNMP OID scheme uses 328 the left-to-right naming scheme. Both ways of naming have been 329 equally popular and we just have to choose one of them. 331 We chose the left-to-right naming scheme for naming services. Using 332 this convention a domain a.b.c will mean that "a" is the root SDN; 333 that "b" is the child domain of "a", and "c" is the child domain of 334 "b". The naming convention can be made into a tree with the left-most 335 node being the root and the right-most nodes being the leaves. 337 An example tree of services is Figure-1. This Figure should be 338 regarded illustrative only, and meant to describe the concept of 339 hierarchical SDNs. A sufficiently comprehensive description of 340 service hierarchies is deferred to a later document. 342 +----------+ 343 | services | 344 +----------+ 345 | 346 +----------------------+----------------------+ 347 | | | 348 +------+ +------+ +------+ 349 | iaas | | paas | | saas | 350 +------+ +------+ +------+ 351 | | | 352 +--------+ . . . . . . 353 | 354 | +---------+ 355 +---| compute | 356 | +---------+ 357 | +---------+ 358 +---| storage | 359 | +---------+ 360 | +---------+ 361 +---| network |---+ 362 +---------+ | 363 | +-----------+ 364 +---| switching | 365 | +-----------+ 366 | +-----------+ 367 +---| routing | 368 | +-----------+ 369 | +-----------+ 370 +---| transport | 371 | +-----------+ 372 | +-----------+ 373 +---|application|--+ 374 +-----------+ | +----------+ 375 +--| dpi | 376 | +----------+ 377 | +----------+ 378 +--| firewall | 379 | +----------+ 380 | +----------+ 381 +--| waas | 382 | +----------+ 383 | +----------+ 384 +--| vpn | 385 +----------+ 387 Figure-1 Service Domain Names 389 Using this kind of domain naming convention, we can define domains 390 like iaas.network.switching, or iaas.network.security. 392 6. Service Syntax Specification 394 Once Service Domain Names are defined, each domain must have an 395 associated set of attributes, which collectively define the "syntax" 396 through which that domain is defined. An abstract language is 397 required to define domain attributes, and we recommend use of XML to 398 define all XML attributes. 400 6.1. XML Schemas for Service Syntax 402 The syntax of each XML defined service domain can be defined through 403 an XML schema, within which we define domain elements and attributes. 404 Since the SDNs form a hierarchy, it is easy to inherit one domain's 405 attributes into another. XML inherit mechanisms can be used to 406 inherit one domain's attributes into another. 408 By using hierarchical XML schemes and inheriting namespaces, the 409 functionality that has been built for one domain can be easily re- 410 used by the inheriting domain. A new service definition only needs to 411 define what it has added or modified on top of the existing domains. 412 This will simplify the creation of new services, in a manner 413 analogous to how object-oriented design (object inheritance) greatly 414 improves code-reuse and accelerates application development. 416 Appendix A describes example XML schemas for domains iaas.network and 417 iaas.network.routing. The first defines an element "hub" while the 418 second defines an element "router". The "router" element inherits 419 attributes from the iaas.network schema, by adding an "ip-address" 420 and "subnet-mask" elements to it. These schemas can be used to 421 construct SDF payloads for a hub and router. This is shown below. 423 ------------------ Example: SDF payload for a HUB ------------------ 425 426 427 430 431 Ethernet 432 1 433 1 434 435 < d1:interface> 436 Ethernet 437 1 438 2 439 440 441 443 -------------------------------------------------------------------- 445 ----------------- Example: SDF payload for a ROUTER ---------------- 447 448 449 452 453 Ethernet 454 1 455 1 456 10.10.10.1 457 255.255.255.0 458 459 460 Ethernet 461 1 462 2 463 10.10.10.2 464 255.255.255.0 465 466 467 469 -------------------------------------------------------------------- 471 The XML element is used to encapsulate the domain-specific 472 service description in a standard way that the receiver can 473 interpret. This element has the following attributes: 475 - A Domain Name Attribute - this is the SDN for payload contained 476 within the tag. It helps the receiver identify the SDN 477 and determine if the receiver knows how to deal with the payload. 479 - A Type Attribute - this has two possible values: "capability" and 480 "availability". The "capability" attribute is used in requesting 481 actions by the receiver. The "availability" attribute is used by 482 the service to advertize its service availabilities. With 483 virtualized services, the availability reduces as services are 484 allocated to users, although the capability remains unchanged. The 485 capability would however change in case of partial or total 486 service failures, such as software or hardware failures. 488 - The Def Attribute - this allows standard and non-standard payloads 489 to be sent in the same manner. For standard domains, the attribute 490 has the value "sdn" and for non-standard domains the attribute is 491 set to "vsd". Non-standard domains are defined in Section 6.2. 493 The domain scheme described here can be used in conjunction with 494 existing standard or non-standard service definitions. For instance, 495 the domain scheme may be used in conjunction with an existing 496 specification such as OVF [OVF] or others to be defined. The OVF 497 scheme will need to be identified by a SDN, such as 498 iaas.compute.virtual. This is shown below. 500 501 502 504 6.2. Vendor Specific Domains (VSD) 506 There may be a need for vendors to deliver service customizations 507 that are non-standard or pre-standard. Such services may be defined 508 in exactly the same manner as standard service definitions. To 509 describe the fact that this is a vendor specific domain, and may not 510 be understood by every network element, the domain has to be (a) 511 given a name that does not overlap with standard domain names, and 512 (b) identified by the def="vsd" attribute in the element. 514 For example, a "vendor" may define their private domain 515 "vendor.router" and this domain would be referred to as follows. 517 518 519 521 Vendor defined domains MUST begin with the vendor's name. VSDs may be 522 treated differently in how they are used across boundaries. For 523 instance, a customer might advertize VSDs to selected customers. 525 7. Domain Semantics Rules (DSR) 527 XML schemas associated with domains define the elements, their 528 attributes and the syntax for describing a elements and attributes. 530 The XML schema does not give us the semantics of a domain's elements 531 and attributes. This gap has to be filled up in other ways. 533 What is domain semantics? Domain semantics is the relation between 534 attributes within and across domains. This relation is seen in how 535 resources (logical, virtual or physical) are allocated to populate 536 elements and attributes in XML documents in a coordinated fashion. 538 For example, the MAC address assigned to a VM must be unique amongst 539 the hosts that the VM is going to interact with. This uniqueness is a 540 relation between the various MAC addresses. Then, the MAC address on 541 the VM must also be in access-lists on the network. This is a 542 relation between the compute and network domains. The network based 543 storage must be mapped to file systems on the host, requiring a 544 mapping of logical and virtual resources across compute and storage 545 domains. To restrict access to the storage to certain hosts, there 546 has to be a relation between host, network and storage domains. 548 Relations between attributes within and across domains constrain 549 resource allocation. When resources are allocated according to these 550 constraints, services created across different domains work together 551 seamlessly in the intended way. Domain semantics is the relation 552 between attributes within a domain and across domains. 554 Therefore, after we have XML schemas for each domain with the ability 555 to inherit domains, there is still a need to express the relations 556 between attributes. Again, this is easily achieved if the domain 557 schema is expressed in a high-level language such as XML. XML 558 technologies such as Object Constraint Language [OCL] and Schematron 559 [STRON] can be used to describe semantic relations. An example 560 constraint is shown below where the VLAN configured on a VM interface 561 is equal to the VLAN access allowed on the network switch. 563 /iaas.network.switching/port-list[0]/acl@vlan = 564 /iaas.compute/vm-list[0]/interface-list[0]/vlan 566 Semantic rules that specify relations between domain attributes 567 SHOULD be defined in separate Domain Semantics Rules (DSR) files. 568 Each DSR file may be associated with a Workflow, as the rules are 569 often likely to be user or service specific. Similar to hierarchical 570 domain specifications, it is also possible to define parent and child 571 DSR files. Specification of semantics through DSR files, allows a 572 service to be rapidly customized, and new services to be created. 574 A reusable hierarchy of DSR files MAY be defined to facilitate 575 service relations across domains. Specification of this hierarchy is 576 left to a later effort and contributions are welcome. 578 8. Service Workflows Description Language (SWDL) 580 Workflows are needed to group tasks sequentially or in parallel. Such 581 grouping may bundle domain names and may involve many target devices. 582 For instance, it may be necessary to treat the creation of a virtual 583 machine and its associated network configuration as a single task 584 group. Failure of one of the tasks in this group may result in the 585 reversal of the entire task group. 587 To construct a flowchart using tasks, task groups, and workflows, we 588 need to (a) label individual items in the workflow, and (b) order the 589 items using "prev" and "next" tags. Each Workflow MUST have an 590 associated Workflow Anchor (WA). The WA is the controller of the 591 Workflow and the only one authorized to execute the Workflow. The 592 Anchor attribute MAY have more than one Proxy to execute it. 594 The following XML captures these requirements. 596 599 workflow description 600 601 taskgroup description 602 604 605 606 607 608 609 611 The XML schema for Workflows and Tasks is defined in Section 9. The 612 "type" of each Task must map to one of the messages in SOP. Sending 613 and receiving those messages can be expected of a SOP Proxy. The 614 attribute of "server" defines the network element that will process 615 the task or workflow. The "server" could be a SN, Proxy, WS, etc. The 616 "instance" attribute in the workflow identifies an instance of a 617 Workflow. It MUST be set equal to the Exchange header value in the 618 SOP message (this relates SOP messages with SDF content). 620 9. Formal Syntax 622 The XML schema for SDF is given below. This is an initial attempt and 623 likely to evolve with inputs. Contributions are welcome here. 625 626 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 699 10. Security Considerations 701 Validation of SDF payloads is defined in the SOP Architecture [ARCH]. 702 Security aspects of SDF are covered in the SOP document [SOP]. 704 11. IANA Considerations 706 NA 708 12. Conclusions 710 SDF specifies four kinds of information needed to describe services. 711 This information can be transported as content of SOP messages. We 712 use XML technologies and their capabilities to represent a service 713 domain's syntax and semantics. Use of SDF has following benefits: 715 - Relation between service domains (Domain Hierarchy). The SDN 716 convention allows multiple service "domains" to be defined, and 717 the relation between these domains, by inheriting other domains. 718 Advantages of this approach can be likened to benefits from 719 object-oriented software, where new objects can be developed by 720 reusing functionality in existing objects. 722 - Domain syntax validation (Service Schema). This helps define the 723 format in which service requests/updates must be made and 724 mechanism to validate a request/update syntax. 726 - Domain semantics for resource allocation (Relational Rules). This 727 helps relate resources in one service domain to resources in other 728 service domains to make them work coherently and seamlessly. 730 - Workflow description (Service Workflow Description Language). This 731 helps define different task groupings and task order that may use 732 one or more service domains, to orchestrate a complex service. 734 13. References 736 13.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 13.2. Informative References 743 [NIST] DRAFT Cloud Computing Synopsis and Recommendations 744 http://csrc.nist.gov/publications/drafts/800-146/Draft- 745 NIST-SP800-146.pdf 747 [REQT] Service Orchestration Protocol Requirements 748 http://www.ietf.org/id/draft-dalela-orchestration-00.txt 750 [ARCH] Service Orchestration Protocol Network Architecture 751 http://www.ietf.org/id/draft-dalela-sop-architecture-00.txt 753 [SOP] Service Orchestration Protocol 754 http://www.ietf.org/id/draft-dalela-sop-00.txt 756 [OVF] Open Virtualization Format 757 http://xml.coverpages.org/DMTF-OVF-v10-DSP0243.pdf 759 [XSD] XML Schema Description 760 http://www.w3.org/XML/Schema 762 [OCL] Object Constraint Language 763 http://www.omg.org/technology/documents/modeling_spec_catal 764 og.htm#OCL 766 [STRON] Schematron Specification 767 http://www.schematron.com/spec.html 769 14. Acknowledgments 771 This document was prepared using 2-Word-v2.0.template.dot. 773 Appendix A. Example XML Schemas 775 This Appendix illustrates the use of XML schemas for designing 776 hierarchical service domains. Appendix A.1. gives an example schema 777 for the iaas.network domain, eventually defining a "hub". Appendix 778 A.2. shows how the iaas.network schema can be extended to define a 779 iaas.network.routing schema, eventually defining a "router". 781 A.1. Example XML Schema for iaas.network SDN 783 This schema defines the "interface" element and a "hub" element as 784 collection "interface" elements. 786 ----------------------- file:iaas.network.xsd --------------------- 788 789 792 794 795 796 797 798 799 801 802 803 804 805 806 807 809 810 811 813 814 ------------------------------------------------------------------- 816 A.2. Example XML Schema for iaas.network.routing SDN 818 This schema inherits the schema from iaas.network. It adds the 819 elements "ip-address" and "subnet-mask" to the "interface" creating 820 L3 interfaces. A collection of such interfaces can now form a 821 "router" element. 823 ------------------- file:iaas.network.routing.xsd ----------------- 825 826 829 830 832 833 834 835 836 837 838 839 841 842 843 845 846 ------------------------------------------------------------------- 847 Authors' Addresses 849 Ashish Dalela 850 Cisco Systems 851 Cessna Business Park 852 Bangalore 853 India 560037 855 Email: adalela@cisco.com 857 Mike Hammer 858 Reston 859 Virginia 860 USA 20190 862 Email: mphmmr@gmail.com 864 Monique Morrow 865 Cisco Systems [Switzerland] GmbH 866 Richistrasse 7 867 CH-8304 868 Walllisellen 869 Switzerland 871 Email: mmorrow@cisco.com 873 Peter Tomsu 874 Cisco Systems Austria GmbH 875 30 Floor, Millennium Tower 876 Handelskai 94-96 877 A-1200 Vienna 878 Austria 880 Email: ptomsu@cisco.com