VWRAP Deployment and trust patterns
draft-levine-vwrap-deploy-01

Abstract

Architectural layering, patterns and trust points for VWRAP

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 August 28, 2010.

Copyright Notice

Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Requirements Language
2.  Introduction
3.  Virtual Worlds Overview
4.  Mechanisms, Services, Domains, Policy
5.  Servers, Services, Mechanisms and Named entities
6.  Mechanisms and Messages
    6.1.  idempotency and transport reliability
7.  Deployment patterns
    7.1.  Second Life Agent Domain / Region Domain Split
    7.2.  Standalone OpenSim Region model
    7.3.  OpenSim VWRAP + Asset reflector + Agent Service
    7.4.  OpenSim UGAIM grid model
    7.5.  Hypergrid
    7.6.  Hypergrid and Cable Beach
    7.7.  Multi-hosted asset deployment
    7.8.  Factored Service Models
8.  Possible Domain definitions
9.  Trust and policy issues
    9.1.  Policy Requirements
    9.2.  Grid Access authentication
    9.3.  Content Management
        9.3.1.  content flows through VWs
            9.3.1.1.  Content delivery models
            9.3.1.2.  multiple representations
    9.4.  Content Metadata
10.  IANA Considerations
11.  Security Considerations
12.  References
    12.1.  Normative References
    12.2.  Informative References
Appendix A.  Additional Stuff
§  Author's Address

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Introduction

This draft is an extension and follow on draft to OGPX layering and architectural patterns, draft-levine-ogp-layering-00

This note focuses on design patterns and architectural choices which will permit the VWRAP specifications to adapt to a wide range of deployment patterns, within the basic VWRAP 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 inter operate in a principled fashion.

This draft includes patterns for assembling VWRAP services into usable systems and patterns for alternative implementations of various VWRAP services to allow varying approaches to service and content delivery. This draft is intended to focus attention on the service design choices which will allow a single specification to support a range of deployed services.

3.  Virtual Worlds Overview

To clarify the nature of the VWRAP specifications, a brief summary of what is meant by a virtual world and how the VWRAP specification approaches creating a virtual world.

A virtual world is a shared space in which users, represented as avatars can interact with each other and a simulated environment. VWRAP focuses on a set of virtual worlds with persistent simulations, rich visual components and common approach to simulation. This approach follows the general pattern established by Linden Lab(TM)'s Second Life offering.

The core task of a virtual world is to create the shared experience of multiple users interacting in a simulated space. Actions by users, and changes in the state of the shared experience are merged to form a series of successive states which are presented to users. VWRAP virtual worlds approach this task by creating a region which manages the shared simulation, and defining how various services collaborate to allow clients to join the simulation, interact with it, and receive the information they need in order to present the shared environment to their users.

User1           User2
   |                  |
Client1         Client2
     \               /
      \            /
     VWRAP Services
(Region + other)

Effectively the two users connected via a pair of clients use the services defined by the VWRAP specifications to experience a virtual world.

The VWRAP specifications focus on defining the services and interaction patterns required to permit a client to:

• Authenticate and establish an association with an initial service point
• Request that an avatar associated with the user be placed into a virtual region
• Be informed of the state of a virtual space when they enter it
• Be informed of changes to the state of the virtual space as they occur
• Inform the virtual space of actions the user is taking
• Interact with services which store items to be introduced into the virtual space
• Interact with other users in the virtual world
• Interact with administrative services within the virtual space

The VWRAP specifications also describe the services and interaction patterns between services which permit:

• Virtual Spaces to fetch and store virtual items
• Manage the location of users within virtual spaces (presence)
• Manage message delivery to remote users within virtual spaces
• Provide externalized interfaces to items and users within virtual spaces

Note: The above lists are not intended to be exhaustive. However, if any major services which are going to be defined by VWRAP are missing, they should be noted and added.

4.  Mechanisms, Services, Domains, Policy

When completed, the VWRAP specifications will define:

• a set of underlying service delivery mechanisms
• a set of services delivered over these mechanisms
• clusters of related services, called domains
• mechanisms to apply policy to specific services

The model of "domain" is not fully defined in the current specifications. Several possible approaches to defining "domains" or "clusters" are described here, in hope of stimulating agreement on a concise definition.

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

5.  Servers, Services, Mechanisms and Named entities

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

• Service: a named set of REST style resources which accepts a series of messages to perform a task. We explicitly do not mean a deplSuoyed service such as the Second Life(tm) service. Services are model using REST semantics. The specifications explicitly decouple service semantics from HTTP delivery.
• Region: A named portion of virtual space. A Region is addressable, via a URI and manages a portion of simulated space. Regions are not bound onto specific computational models. From the perspective of the protocol, the address and services provided defines the region.
• Agent: The state and services representing a user within the virtual world
• Policy: A described behavior of a service within the VWRAP specifications.
• Avatar: A visual representation of an Agent within the virtual world.
• Asset: A set of digital content for use in VWRAP. An asset may have presentation data, simulation data and meta data. Simulatoin data is used in the procerss of simulating the content. It might include a script, physical properties of an item for smiulatoin purposes, a collision meshor similar simulation focused items. Presentation data is used by the client to present the asset to end users.Textures, sounds, animtations, and meshes are examples of presentatoin data. meta data is used to describe and manage the asset. Licenses, author data, descriptive data for accessability are examples of meta-data
• Primitive Object: A data structure describing a visual component in a simulation. Historically these have been constructive geometric objects in Second Life like worlds, but the VWRAP specifications assume that the set of defined primitive objects will grow to included meshes and other low geometric formats. Primitive objects can be assembled into larger compound objects.
• Simulation: The process of modeling the elements of a virtual region. The computational processing which creates a series of successive scenes containing the Avatars, and Assets within a region.
• Delivery Mechanism: A web service, or structured LLIDL/LLSD message used to request a service or deliver a notification of a status change in a resource.

6.  Mechanisms and Messages

In order to support the full set of use cases, the VWRAP specifications model several types of interaction.

Many interactions are modeled via simple REST based capabilities, where the client or a service invokes a direct service to get data or cause an action to take place. Examples include fetching a virtual asset or requesting information about a virtual resource.

Some VWRAP interactions establish an ongoing delivery of messages. As an example, when an agent is placed in a virtual region, a series of updates, informing the client of status changes in the region is implicit in the virtual world model. There are a number of possible models for delivering the status updates, including having the client fetch repeated complete documents containing the state of the region. In practice, it is far more efficient to only send changed elements. Notionally, these updates can be pushed or pulled.

Some VWRAP interactions are very low level, with low latency and small size. Actions such as an avatar taking a step, a user changing the current position of an object in a shared space, text chat and so on. These actions often are very "event like." Event like messages can be delivered several ways. The current implementations tend to deliver these messages via UDP, although some event notifications are fetched via polled queues.

6.1.  idempotency and transport reliability

For both ongoing notification and low level "event" like messages, Idem potency and Reliability become important considerations. A significant simplification can be achieved if event like messages don't require reliable delivery. Making such messages idempotent (Meaning repeated processing does not change the state of the resource more than once) simplifies re-sending messages. Designing the messages so that a series of messages, delivered out of order can be processed by discarding late messages also simplifies unreliable transport. In particular, the choice of "step forward at time X" vs. "Step forward from position X,Y,Z at time X" means that in the former, one has to reliably deliver all the step messages, where as in the later, one can skip a step message, or repeat it, and the resulting state will be the same.

7.  Deployment patterns

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

7.1.  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, inherently have their own event queue or trust domain.

7.2.  Standalone OpenSim Region model

In the Standalone OpenSim deployment model, all of the services 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 separate processes within the server.

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

7.3.  OpenSim VWRAP + Asset reflector + Agent Service

In this deployment pattern, one or more OpenSim regions are hosted, each as a separate server. An separate 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.

7.4.  OpenSim UGAIM grid model

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

7.5.  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 their avatars between the regions. Service requests related to the back end services 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.

7.6.  Hypergrid and Cable Beach

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

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

7.8.  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 services may be used to host part or all of a VWRAP deployment. In such a deployment model, services deployed within a cloud may deploy one or more event queue endpoints or service and trust endpoints 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 computing fabric should be supported.

8.  Possible Domain definitions

Given the above set of deployment patterns several possible ways of usefully defining "domain" seem possible.

One could conclude that the specification should ignore domain as a structuring concept and instead focus on describing the services needed to deliver the desired results, and allow domain patterns to be entirely deployment artifacts.

One could focus on shared infra structural elements. In such a model domains might be defined by sharing a common set of seed caps, or a common event queue.

Security and administration form another possible way of delineating domains. It is unclear if this differs in a meaningful way from the first choice, as administrative domains tend to be purely artifacts of deployers.

9.  Trust and policy issues

Policy, in VWRAP is a deployer chosen set of constraints filtering the behavior of a service. A policy may require a user to have presented a proof token before using a service. VWRAP does not provide an policy expression language, nor does VWRAP mandate specific policies. VWRAP's support of policies is limited to providing the mechanisms for services to include added content needed in support of policy decisions, and to reflect the results of policy decisions to the invokers of services. This level of support permits a graceful degradation of service when a policy limits the use of a service, and follows the web practice of separating mechanism from policy.

9.1.  Policy Requirements

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

• End user identity token
• Requesting Service identity token
• 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 their policy requirements in a predictable and principled fashion.

9.2.  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 agent domain. Several emerging Internet approaches, such as openId or OAuth are possible mechanisms which may be used to satisfy this need.

9.3.  Content Management

One of the challenges facing a virtual worlds environment is determining how digital content should be shared. The VWRAP specifications split this problem into mechanisms and policies. The following sections focus on describing several approaches and the places they impinge on the mechanisms being defined in VWRAP.

Content Management includes, but is not limited to:

• Labeling content with meta data to facilitate its management
• Identifying policy enforcement points for content management

9.3.1.  content flows through VWs

           +-------------+            +----------+             +-------+
Insertion->| Asset Store |--"rez" --->|  Region  |--Present--->| client|
           +-------------+            +----------+             +-------+

This diagram describes some of the key moments as a digital item flows through a virtual world. The item is inserted into and stored within the virtual world's services. It is then added to a virtual world's region (rezzed), which makes it available for simulation and, finally presented to client(s) for viewing.

Notice that this is notional. How the various services are deployed and where trust boundaries might be placed is not described. Temporally the insertion, "rez" and presentation are separable by arbitrary amounts of time (including none). Insertion may be from an external library, a tool chain, or other services. It is the moment when the content in question enters into the purview of the virtual world.

The process of adding an item to a virtual region, copies some or all of its content. This may be as little as a reference to the actual item and an extremely simplified representation for physical simulation, or it may be a complete copy of the item in all of its particulars. The most common implementation has the entire item copied to the region for simulation, and delivery to the client.

9.3.1.1.  Content delivery models

A range of possible representations can be passed to a region for simulation. Full content can be passed to regions, or a subset of content, or only references to most content. The VWRAP specifications should permit as broad a range of content delivery models as possible.

One end of the spectrum involved passing the full content, including the full geometric description, and all the information necessary for a client to render the content, the information necessary to simulate the object at a physical level, and any scripted attachments which automate the behavior of the item.

The other end of the delivery spectrum involves passing only a URI or capability used to access the rendering information and a collision mesh,and related data for physical simulation. In such a model, the client is responsible for fetching the additional information needed to render the item's visual presence from a separate service. This fetch can be done under the credentials of the end user viewing the material, and divorces the simulation from the trust chain needed to manage content. Any automation is done on a separate host which the content creator or owner trusts, interacting with the object through remoted interfaces.

Notice that various choices may conceal or reveal information about both content providers and end users. An indirected URI fetched by a client exposes itself, of course, but also exposes the client's IP address to the service hosting the content. This is common web practice, but may be somewhat suprising to users used to having thier content served only by hosting servers.

9.3.1.2.  multiple representations

A second mechanism for managing content delivery is to provide multiple versions of an item, and pass different versions, depending on the trust level which exists between two services. Such a model can be applied at all the steps in the VWRAP protocols. An asset server may host multiple versions of an object and pass appropriate versions to requesters. A region could be sent multiple representations of an item, and pass the appropriate one down to clients based on the relationship between the client and the region. Alternative content can be used to account for degrees of trust as well as richness of a given client. Multiple representations can be combined with redirection to permit a low fidelity version to be distributed widely, with a reference to a higher quality version which can be fetched directly should the end user be authorized.

9.4.  Content Metadata

While metadata includes many types of data, in this section, we are speakign only about metadata specifically intended for use in content mnagaement.

Content meta data for content management allows the content creator or Asset owner to mark the content with additional data describing its intended or legally required content management rules. While such markup can't in and of itself enforce proper behavior of services, it provides a well defined place for services which are following a set of rules. In general, the VWRAP specifications define the affordances needed to permit such policy enforcement, but leave policy enforcement and policy mechanisms to deployers.

10.  IANA Considerations

This memo includes no request to IANA.

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

12.  References

12.1. Normative References

12.2. Informative References

Appendix A.  Additional Stuff

This becomes an Appendix.

Author's Address