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]