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

Versions: 00

OGPX pre BOF                                              D. Levine, Ed.
Internet-Draft                             IBM Thomas J. Watson Research
Intended status: Informational                                    Center
Expires: January 14, 2010                                  July 13, 2009


                OGPX layering and architectural patterns
                      draft-levine-ogp-layering-00

Status of this Memo

   This Internet-Draft is submitted to IETF 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 January 14, 2010.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Architectural layering and patterns for OGPX.





Levine                  Expires January 14, 2010                [Page 1]


Internet-Draft                OGPX layering                    July 2009


Table of Contents

   1.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Mechanisms, Services, Domains, Policy . . . . . . . . . . . . . 3
   4.  Deployment patterns . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Second Life Agent Domain / Region Domain Split  . . . . . . . . 4
   6.  Standalone OpenSim Region model . . . . . . . . . . . . . . . . 4
   7.  OpenSim OGP + Asset reflector + Agent Service . . . . . . . . . 5
   8.  OpenSim UGAIM grid model  . . . . . . . . . . . . . . . . . . . 5
   9.  Hypergrid . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   10. Hypergrid and Cable Beach . . . . . . . . . . . . . . . . . . . 5
   11. Multi-hosted asset deployment . . . . . . . . . . . . . . . . . 6
   12. Factored Service Models . . . . . . . . . . . . . . . . . . . . 6
   13. Policy Requirements . . . . . . . . . . . . . . . . . . . . . . 6
   14. Grid Access authentication  . . . . . . . . . . . . . . . . . . 6
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   16. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     17.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
     17.2.  Informative References . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7




























Levine                  Expires January 14, 2010                [Page 2]


Internet-Draft                OGPX layering                    July 2009


1.  Requirements Language

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


2.  Introduction

   This note focuses on design patterns and architectural choices which
   will permit the OGPX specifications to adapt to a wide range of
   deployment patterns, within the basic OGXP remit, and support the use
   of policy to permit the architecture to enable virtual spaces with
   very different policies toward security, intellectual property,
   identity, and economics to share common infrastructure and to
   interoperate in a principled fashion.

   This note is preliminary in nature, and is primarily intended to
   drive a discussion on the specific nature of the requirements for
   managing diverse deployments, and suppoting diverse policies.


3.  Mechanisms, Services, Domains, Policy

   When completed, the OGPX specifications will define:

   o  a set of underlying service delivery mechanisms

   o  a set of services delivered over these mechanisms

   o  clusters of related services, called domains

   o  mechanisms to apply policy to specific services

   The most commonly mentioned partition of services into domains is the
   split between "agent" and "region" domains proposed by Linden Lab.
   This partition separates services associated with the user's identity
   and information, the "agent domain," from services associated with
   virtual space, the "region domain"

   In order to discuss patterns of clustering and service delivery, it
   is necessary to discuss what is mean by "domain" and also look more
   deeply into both the notions of a cluster of services, and also
   discuss possible deployment patterns Servers, Services and Named
   entities

   In order to avoid confusion, in this note, we will define a number of
   terms very precisely:



Levine                  Expires January 14, 2010                [Page 3]


Internet-Draft                OGPX layering                    July 2009


   Service: a named set of REST style resources which accepts a series
   of messages to perform a task.  We explicitly do not mean a deployed
   service such as the Second Life(tm) service.

   Server: A computer offering up one or more named services

   Region: A named portion of virtual space

   Agent: The state and services representing a user within the virtual
   world

   Policy: A described behavior of a service within the OGPX
   specications.


4.  Deployment patterns

   To motivate the discussion, we will describe several plausible
   deployment patterns for OGPX based systems.  Each of these deployment
   patterns should be viewed as a use case for the OGPX specifications.
   The specifications should provide sufficient expresivity of service
   endpoints, and trust boundaries to support all of the described
   patterns.


5.  Second Life Agent Domain / Region Domain Split

   This deployment pattern represents the pattern Linden Lab proposed in
   its initial discussions on second generation architecture in 2007.
   It offloads any services which are not germane to managing a virtual
   space to an "agent" domain, focused, on the services which are
   specific, not to the virtual space, but the user's agent.

   In this pattern, the viewer is typically connected to one or more
   regions, and one agent domain.  The agent domain acts as a unitary
   focus for all services associated with the agent.  When accessing
   other services hosted by a deployer other than the hoster of the
   agent domain, the agent domain acts as the trust source, managing the
   agent (and user's) access to other regions.

   In this deployment pattern, back end services, such as assets and
   inventory are accessed via the agent domain, do not, inhenrently have
   thier own event queue or trust domain.


6.  Standalone OpenSim Region model

   In the Standalone OpenSim deployment model, all of the services



Levine                  Expires January 14, 2010                [Page 4]


Internet-Draft                OGPX layering                    July 2009


   comprising a Region, an Agent Domain, and the supporting services
   used by these services are hosted on a single server.  A single event
   queue may manage connectivity to the services, or several event
   queues, with the services being hosted as seperate processes within
   the server.

   Historically, a standalone OpenSim represents a single fully trusted
   domain, where there are no seperate trust components or policies.


7.  OpenSim OGP + Asset reflector + Agent Service

   In this deployment pattern, one or more OpenSim regions are hosted,
   each as a seperate server.  An seperate agent domain acts as the
   trust authority, and login component for the deployment.  Inventory
   and Asset requests are reflected from individual regions to asset and
   inventory services, hosted either in a standalone fashion, or as part
   of an OpenSim region.


8.  OpenSim UGAIM grid model

   This is the current (Soon to be deprecated) OpenSim Grid model.  In
   this model, a seperate login service (not an agent domain) is hosted
   on one server ans a collection of backend services are shared by one
   or more Region Simulators.  The entire grid forms a single trust
   model.


9.  Hypergrid

   In this model, each Region is hosted in either Standalone, or UGAIM
   style Grid mode.  Specific links between regions are created, which
   define a two way mapping, permitting users to move thier avatars
   between the regions.  Service requests related to the back end
   servcies for these avatars are directed back to the originating
   service.  Trust, if any is established in the process of creating the
   explicit link between the regions.


10.  Hypergrid and Cable Beach

   Hypergrid can be combined with cable beach, so that assets are
   fetched directly from a shared asset server, and trust between the
   asset server, and between the regions and the user is managed by the
   client directly.





Levine                  Expires January 14, 2010                [Page 5]


Internet-Draft                OGPX layering                    July 2009


11.  Multi-hosted asset deployment

   This is a case in which there are multiple back ends supporting
   multiple sets of assets.  Trust is established either per the Agent
   Domain model, between services, and the agent's agent domain, or
   between regions, in hpyergrid fashion, or directly between the client
   and the asset services, per the cable beach model.


12.  Factored Service Models

   There is nothing inherent in the requirements of a virtual world
   deployment that specific back end services be clustered into two
   domains, nor that a single server or logical endpoint host all of the
   services which comprise a deployment.  Cloud deployed servics may be
   used to host part or all of a OGPX deployment.  In such a deployment
   model, services deployed within a cloud may deploy one or more event
   queue endpoints or service and trust endopints to connect to clients.

   Factoring of services is not exclusive to back end services, the
   agent domain, or regions.  Deployment models in which regions share
   services, or in which the services comprising a region are deployed
   on a distributed computuing fabric should be supported.


13.  Policy Requirements

   Policy decisions may be made by services on the basis of:

   o  End user identity token

   o  Requesting Service identity token

   o  Service specific token (Proof of license, proof of TOS signature,
      etc.)

   In order to permit policy decisions to be made by services, a number
   of token may presented to the service.  These tokens will likely be
   supported as optional additions to the protocols, inserted in slots
   in the protocol messages defined by the services.  This permits
   services to optionally require additional inputs in order to satisfy
   thier policy requirments in a predictcable and princpled fashion.


14.  Grid Access authentication

   One policy choice grid deployers may make, is to require a login or
   authentications to be made to the grid's authentication service or



Levine                  Expires January 14, 2010                [Page 6]


Internet-Draft                OGPX layering                    July 2009


   agent domain.  Several emerging internet approaches, such as openId
   or OAuth are possible mechanisms which may be used to satisfy this
   need.


15.  IANA Considerations

   This memo includes no request to IANA.


16.  Security Considerations

   This draft primarily defines requirements and use cases, as well as a
   description of policy management approaches.  Policy management
   includes control of choices which affect security.  To the extent
   that requirements and use cases permit poor security choices to be
   made when deploying services security of a deployed system could be
   compromised by those considerations.


17.  References

17.1.  Normative References

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

17.2.  Informative References

   [cable]    Intel, "Cable Beach Design Wiki", 2009, <http://
              code.google.com/p/cablebeach/wiki/CableBeachCore1_0>.

   [caps]     Linden Lab, "Open Grid Protocol: Foundation", 2009,
              <http://tools.ietf.org/html/draft-lentczner-ogp-base-00>.

   [intro]    Linden Lab, "Open Grid Protocol: Foundation", 2009,
              <http://tools.ietf.org/html/draft-hamrick-ogp-intro-00>.


Appendix A.  Additional Stuff

   This becomes an Appendix.









Levine                  Expires January 14, 2010                [Page 7]


Internet-Draft                OGPX layering                    July 2009


Author's Address

   David W. levine (editor)
   IBM Thomas J. Watson Research Center
   19 Skyline Drive
   Hawthorn, New York  10532
   USA

   Phone: +1 914-784-7427
   Email: dwl@us.ibm.com









































Levine                  Expires January 14, 2010                [Page 8]


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