idnits 2.17.1 draft-levine-ogp-layering-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2009) is 5398 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OGPX pre BOF D. Levine, Ed. 3 Internet-Draft IBM Thomas J. Watson Research 4 Intended status: Informational Center 5 Expires: January 14, 2010 July 13, 2009 7 OGPX layering and architectural patterns 8 draft-levine-ogp-layering-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 14, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Architectural layering and patterns for OGPX. 48 Table of Contents 50 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Mechanisms, Services, Domains, Policy . . . . . . . . . . . . . 3 53 4. Deployment patterns . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Second Life Agent Domain / Region Domain Split . . . . . . . . 4 55 6. Standalone OpenSim Region model . . . . . . . . . . . . . . . . 4 56 7. OpenSim OGP + Asset reflector + Agent Service . . . . . . . . . 5 57 8. OpenSim UGAIM grid model . . . . . . . . . . . . . . . . . . . 5 58 9. Hypergrid . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 10. Hypergrid and Cable Beach . . . . . . . . . . . . . . . . . . . 5 60 11. Multi-hosted asset deployment . . . . . . . . . . . . . . . . . 6 61 12. Factored Service Models . . . . . . . . . . . . . . . . . . . . 6 62 13. Policy Requirements . . . . . . . . . . . . . . . . . . . . . . 6 63 14. Grid Access authentication . . . . . . . . . . . . . . . . . . 6 64 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 16. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 17.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 17.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Requirements Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 2. Introduction 80 This note focuses on design patterns and architectural choices which 81 will permit the OGPX specifications to adapt to a wide range of 82 deployment patterns, within the basic OGXP remit, and support the use 83 of policy to permit the architecture to enable virtual spaces with 84 very different policies toward security, intellectual property, 85 identity, and economics to share common infrastructure and to 86 interoperate in a principled fashion. 88 This note is preliminary in nature, and is primarily intended to 89 drive a discussion on the specific nature of the requirements for 90 managing diverse deployments, and suppoting diverse policies. 92 3. Mechanisms, Services, Domains, Policy 94 When completed, the OGPX specifications will define: 96 o a set of underlying service delivery mechanisms 98 o a set of services delivered over these mechanisms 100 o clusters of related services, called domains 102 o mechanisms to apply policy to specific services 104 The most commonly mentioned partition of services into domains is the 105 split between "agent" and "region" domains proposed by Linden Lab. 106 This partition separates services associated with the user's identity 107 and information, the "agent domain," from services associated with 108 virtual space, the "region domain" 110 In order to discuss patterns of clustering and service delivery, it 111 is necessary to discuss what is mean by "domain" and also look more 112 deeply into both the notions of a cluster of services, and also 113 discuss possible deployment patterns Servers, Services and Named 114 entities 116 In order to avoid confusion, in this note, we will define a number of 117 terms very precisely: 119 Service: a named set of REST style resources which accepts a series 120 of messages to perform a task. We explicitly do not mean a deployed 121 service such as the Second Life(tm) service. 123 Server: A computer offering up one or more named services 125 Region: A named portion of virtual space 127 Agent: The state and services representing a user within the virtual 128 world 130 Policy: A described behavior of a service within the OGPX 131 specications. 133 4. Deployment patterns 135 To motivate the discussion, we will describe several plausible 136 deployment patterns for OGPX based systems. Each of these deployment 137 patterns should be viewed as a use case for the OGPX specifications. 138 The specifications should provide sufficient expresivity of service 139 endpoints, and trust boundaries to support all of the described 140 patterns. 142 5. Second Life Agent Domain / Region Domain Split 144 This deployment pattern represents the pattern Linden Lab proposed in 145 its initial discussions on second generation architecture in 2007. 146 It offloads any services which are not germane to managing a virtual 147 space to an "agent" domain, focused, on the services which are 148 specific, not to the virtual space, but the user's agent. 150 In this pattern, the viewer is typically connected to one or more 151 regions, and one agent domain. The agent domain acts as a unitary 152 focus for all services associated with the agent. When accessing 153 other services hosted by a deployer other than the hoster of the 154 agent domain, the agent domain acts as the trust source, managing the 155 agent (and user's) access to other regions. 157 In this deployment pattern, back end services, such as assets and 158 inventory are accessed via the agent domain, do not, inhenrently have 159 thier own event queue or trust domain. 161 6. Standalone OpenSim Region model 163 In the Standalone OpenSim deployment model, all of the services 164 comprising a Region, an Agent Domain, and the supporting services 165 used by these services are hosted on a single server. A single event 166 queue may manage connectivity to the services, or several event 167 queues, with the services being hosted as seperate processes within 168 the server. 170 Historically, a standalone OpenSim represents a single fully trusted 171 domain, where there are no seperate trust components or policies. 173 7. OpenSim OGP + Asset reflector + Agent Service 175 In this deployment pattern, one or more OpenSim regions are hosted, 176 each as a seperate server. An seperate agent domain acts as the 177 trust authority, and login component for the deployment. Inventory 178 and Asset requests are reflected from individual regions to asset and 179 inventory services, hosted either in a standalone fashion, or as part 180 of an OpenSim region. 182 8. OpenSim UGAIM grid model 184 This is the current (Soon to be deprecated) OpenSim Grid model. In 185 this model, a seperate login service (not an agent domain) is hosted 186 on one server ans a collection of backend services are shared by one 187 or more Region Simulators. The entire grid forms a single trust 188 model. 190 9. Hypergrid 192 In this model, each Region is hosted in either Standalone, or UGAIM 193 style Grid mode. Specific links between regions are created, which 194 define a two way mapping, permitting users to move thier avatars 195 between the regions. Service requests related to the back end 196 servcies for these avatars are directed back to the originating 197 service. Trust, if any is established in the process of creating the 198 explicit link between the regions. 200 10. Hypergrid and Cable Beach 202 Hypergrid can be combined with cable beach, so that assets are 203 fetched directly from a shared asset server, and trust between the 204 asset server, and between the regions and the user is managed by the 205 client directly. 207 11. Multi-hosted asset deployment 209 This is a case in which there are multiple back ends supporting 210 multiple sets of assets. Trust is established either per the Agent 211 Domain model, between services, and the agent's agent domain, or 212 between regions, in hpyergrid fashion, or directly between the client 213 and the asset services, per the cable beach model. 215 12. Factored Service Models 217 There is nothing inherent in the requirements of a virtual world 218 deployment that specific back end services be clustered into two 219 domains, nor that a single server or logical endpoint host all of the 220 services which comprise a deployment. Cloud deployed servics may be 221 used to host part or all of a OGPX deployment. In such a deployment 222 model, services deployed within a cloud may deploy one or more event 223 queue endpoints or service and trust endopints to connect to clients. 225 Factoring of services is not exclusive to back end services, the 226 agent domain, or regions. Deployment models in which regions share 227 services, or in which the services comprising a region are deployed 228 on a distributed computuing fabric should be supported. 230 13. Policy Requirements 232 Policy decisions may be made by services on the basis of: 234 o End user identity token 236 o Requesting Service identity token 238 o Service specific token (Proof of license, proof of TOS signature, 239 etc.) 241 In order to permit policy decisions to be made by services, a number 242 of token may presented to the service. These tokens will likely be 243 supported as optional additions to the protocols, inserted in slots 244 in the protocol messages defined by the services. This permits 245 services to optionally require additional inputs in order to satisfy 246 thier policy requirments in a predictcable and princpled fashion. 248 14. Grid Access authentication 250 One policy choice grid deployers may make, is to require a login or 251 authentications to be made to the grid's authentication service or 252 agent domain. Several emerging internet approaches, such as openId 253 or OAuth are possible mechanisms which may be used to satisfy this 254 need. 256 15. IANA Considerations 258 This memo includes no request to IANA. 260 16. Security Considerations 262 This draft primarily defines requirements and use cases, as well as a 263 description of policy management approaches. Policy management 264 includes control of choices which affect security. To the extent 265 that requirements and use cases permit poor security choices to be 266 made when deploying services security of a deployed system could be 267 compromised by those considerations. 269 17. References 271 17.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 17.2. Informative References 278 [cable] Intel, "Cable Beach Design Wiki", 2009, . 281 [caps] Linden Lab, "Open Grid Protocol: Foundation", 2009, 282 . 284 [intro] Linden Lab, "Open Grid Protocol: Foundation", 2009, 285 . 287 Appendix A. Additional Stuff 289 This becomes an Appendix. 291 Author's Address 293 David W. levine (editor) 294 IBM Thomas J. Watson Research Center 295 19 Skyline Drive 296 Hawthorn, New York 10532 297 USA 299 Phone: +1 914-784-7427 300 Email: dwl@us.ibm.com