Media Grid logo


Education Grid Requirements Specification : Working Draft

Name: Education Grid Requirements Specification
Status: Working Draft
Revised: 2008-03-07
This version:
Latest version:
Previous version:
  Algom, Avner, Israeli Association of Grid Technologies (Israel)
  Carfora, John, Amherst College (United States)
  Cohen, Michael, University of Aizu (Japan)
  Edlund, Ake, Royal Institute of Technology (Sweden) and
                      Enabling Grids for E-sciencE (EEGE) (Europe)
  Nagel, H. Nicholas, Grid Institute and Boston College (United States)
  Orkin, Jeff, MIT Media Lab (United States)
  Walsh, Aaron E., Grid Institute and Boston College (United States)


This document specifies baseline requirements for the Education Grid. The Education Grid is the network infrastructure that provides services to Immersive Education client platforms. A high-level overview and 1 hour audio tour of several Education Grid requirements is available online at:


Status of This Document

This document is a Working Draft under active development and may be updated, replaced or made obsolete by other documents at any time and without notice. It is inappropriate to use this document as reference material or to cite it as other than “working draft under active development” or "work in progress".

This document should not be considered stable nor should it be normatively referenced. Publication as a Working Draft does not imply endorsement by members and collaborators.

This document has been produced by the Immersive Education Technology Group (IETG). As a Working Draft under active development this document is member-confidential and not to be circulated beyond the Immersive Education Technology Group and related Technology Working Groups (TWGs).

Comments and notes not intended as specification material appears as RED TEXT.

TBD: The acronym TBD is used to indicate material "To Be Determined" for which feedback, comments and discussion are requested.






1. Introduction

This section is informative.

1.1 Media Grid Overview

The Media Grid is a digital media network infrastructure and software-development platform that provides content delivery, storage and processing (compute) services for use by a wide range of networked applications. The Media Grid is powered by service providers (such as rendering farms, clusters, high-performance computer systems, computational grids, and similar systems) that furnish on-demand services to Media Grid clients (users). Client application service requests are received by the Media Grid network over the public Internet and routed to appropriate service providers as the following diagram illustrates:

The Media Grid does not replace or circumvent service providers—it provides open, uniform and simplified access to them. As with the World Wide Web ("Web"), which shields users and developers from the complexity of the Internet, the Media Grid provides a unified view to otherwise complex and potentially closed or proprietary systems. The Web simplifies Internet development and provides a standard browser interface for text-oriented information and basic digital media content. Similarly, the Media Grid makes it easy for developers to access services provided by utility computing vendors, rendering farms, high-performance computing systems, clusters, grids, and other service providers. By making digital media services available through standardized and unified Application Programming Interfaces (APIs), Uniform Resource Identifiers (URIs), Grid services, and Web services the Media Grid provides an open public utility that benefits end users, application developers and service providers.

The Media Grid “spine” combines the public Internet backbone with service providers. The Media Grid spine, in turn, enables any application connected to the Internet to access Media Grid services. The Grid Gateway specification defined in this document details how service providers connect to, and interact with, the Media Grid network. Specification-compliant Grid Gateway software runs on Media Grid network nodes and is responsible for:

  1. Receiving service requests from client applications
  2. Selecting an appropriate service provider(s) based on service request parameters and settings
  3. Converting the open Media Grid service request format into corresponding native format(s) required by service provider(s)
  4. Routing the appropriately formatted service request to the service provider(s)
  5. Recording the transaction (job metering, accounting, and auditing)
  6. Receiving the results from the service provider
  7. Routing the results to the client application

The following diagram illustrates at a high level the basic concept of service request processing and routing:


The Grid Gateway system is similar, in concept, to the Common Gateway Interface (CGI) mechanism defined for the World Wide Web. Whereas the Web's CGI mechanism is a standard for interfacing external applications with Web (HTTP) servers, the Grid Gateway specification defines a standard for interfacing Media Grid clients and middleware with back-end grids, clusters, render farms, scientific workstations, and similar high-performance computing systems. By defining a uniform gateway interface between client-side applications and back-end service provider systems the Media Grid can be extended to support any form of content storage, delivery, or computing system. As the following figure illustrates, Media Grid gateways also enable resource sharing between grids residing across organizational boundaries:



comment on the above section



1.2 Immersive Education Overview

Immersive Education is a Media Grid activity. is a not-for-profit standards organization that is actively applying open standards to specific problem spaces such as education and distance learning, digital libraries, and the impact of digital media on culture and society.

Immersive Education combines interactive 3D graphics, commercial game and simulation technology, virtual reality, voice chat, Web cameras (webcams) and rich digital media with collaborative online course environments and classrooms. Immersive Education uses these and other advanced technologies to take distance learning and self-directed learning to a new level.


Unlike traditional distance learning, Immersive Education is designed to engage students in the same way that today's best video games grab and keep the attention of players. Immersive Education thoughtfully combines interactive virtual reality, simulations and learning games with sophisticated digital media and collaborative online environments. Immersive Education gives students a sense of "being there" even when attending class in person is not possible or practical. This, in turn provides faculty and remote students with the ability to connect and communicate in a way that greatly enhances the learning experience.

Immersive Education is developed by the Immersive Education Initiative, a non-profit international collaboration of universities, colleges, research institutes, consortia and companies that are working together to define and develop open standards, best practices, platforms, and communities of support for virtual worlds, simulation and game-based learning and training systems.



comment on the above section



1.3 Platform Ecosystem and Education Grid Overview

In the context of Immersive Education the term platform refers to any virtual world, simulator or 3D game-based environment that may be used for teaching or training purposes. The Immersive Education platform has evolved considerably over the past decade and the 3rd generation (“next generation”) is now under development. The previous two generations of Immersive Education were based on specific client-side platforms tied to proprietary server-side infrastructures. The future of Immersive Education revolves around multiple client-side platforms working in unison through the server-side Education Grid. Based upon open source technologies and open standards, the Platform Ecosystem and Education Grid will provide educators with a comprehensive end-to-end infrastructure for a new generation of virtual world learning environments, interactive learning games, and simulations.

The following figure illustrates the concept of client-side Immersive Education platforms utilizing Education Grid services:



comment on the above section



1.4 Education Grid Services Overview

The Education Grid will furnish Immersive Education client-side platforms with three types of services:

  1. Content services — storage, delivery, rating, tagging, search and related content services
  2. Collaboration services — simulator, game, multi-user, application sharing, text chat, voice chat, webcam, and related collaboration services
  3. Academic services — assessment, grading, grade posting, course construction, content construction, and related academic services



comment on the above section



2. Baseline Requirements

This section is normative.

2.1 Platform and vendor neutral

The Education Grid must be platform and vendor neutral. Any client-side platform, and any software application from any vendor, may utilize the Education Grid. Platform and vendor neutrality is necessary to enable the broadest base of Immersive Education applications to be developed and to support the individuals and organizations that develop, maintain, and utilize such applications. Platform neutrality implies that a sufficient degree of abstraction will be supported by the Education Grid such that Immersive Education applications may be deployed across multiple hardware and software configurations. Vendor neutrality implies that any organization or individual may develop applications that utilize the Education Grid.

comment on the above section


2.2 Open standards

The Education Grid will be developed using existing and emerging open standards to the extent possible. The Immersive Education Initiative will define, develop and publish new open standards where necessary to facilitate widespread adoption, accessibility and participation by all interested parties.

comment on the above section


2.3 Open access

The Education Grid will be accessible to all organizations and individuals through open and nondiscriminatory usage policies and procedures. Students, educators, public institutions, private corporations and any other interested parties will have access to Education Grid services as well as all materials published and produced by the Immersive Education Initiative in support of the Education Grid and Immersive Education.

comment on the above section


2.4 Open APIs and interfaces

To the extent possible the Education Grid will be built using existing open standards for Internet-based communications and data transfer (i.e., TCP/IP, HTTP, etc.). The Immersive Education Initiative will design, develop, document and publish open Application Programmer Interfaces (APIs), protocols, and interfaces to provide software developers with comprehensive, flexible and open access to the Education Grid.

comment on the above section


2.5 Open and interoperable file formats

Immersive Education environments, and the various digital media content assets that they are comprised of, must be based on open file formats to the extent possible in order to enable interoperability and long-term durability (i.e., archiving, preservation and accessibility in the future). To this end Immersive Education learning environments and discrete content assets that are created using any one hardware/software configuration should be readily transferable to other hardware/software platforms and environments.

comment on the above section


2.6 Open hosting with conformance and compatibility clauses

Hosting and distribution of Immersive Education content may be achieved via grid, client-server, and/or peer-to-peer server software and network infrastructures. Because the Education Grid is based on an open and distributed architecture Education Grid "nodes" may be hosted (owned and operated) by any organization or individual. Hosting will be open to any organization or individual under the condition that conformance and compatibility is achieved with relevant Immersive Education technological and operational standards. Compliance test suites will be adopted and/or developed as necessary to certify conformance and ensure that all Education Grid nodes are compatible regardless of where or how they are hosted.

comment on the above section


2.7 Free for education and non-profit use with dual licensing for sustainability

Server and client side software and content may be available under a dual-licensing model, with necessary components available free of charge for educational and not-for-profit use. Sustainability may be achieved through vendor development and licensing of fully-supported implementations, supplemental features, tools and content for for-profit utilization.

comment on the above section


2.8 Support for multiple asset types and content formats

Immersive Education revolves not only around 3D content but also many other asset types and content formats (e.g., text-based content, images, audio lectures, video, etc.). Support for multiple asset types and representational formats is a requirement of the Education Grid and all Immersive Education client-side. The Education Grid must support content services for a variety of modern asset and content formats, whereas client-side platforms must be capable of handling multiple content types natively or provide a framework for pluggable application components to handle existing and, as yet, undeveloped types.

comment on the above section


2.9 Quality control and legal vetting

Immersive Education content (i.e., learning experiences and any digital media content assets they are comprised of) must be adequately reviewed, categorized and tagged with metadata prior to being accepted into the Education Grid. Content submission and review processes may include peer-review and asset tagging by users (lay persons), educators, and domain experts alike. Content may be further categorization by trained digital librarians. Content review and tagging is an ongoing process that shall continue over the entire lifetime of an asset that has entered the system; users, educators, domain experts and digital librarians shall be able to review and tag content continually and at any time.

Content must be properly vetted for distribution and usage rights before being accepted into the Education Grid. Content metadata must therefore identify content authors and copyright holders and also convey licensing and distribution rights.

comment on the above section


2.10 Multi-tiered metadata architecture

The metadata model will include provisions for qualitative analysis and tagging by domain experts, digital librarians, educators and all other users of content. Content search services must support searching by any level of metadata and by any combination of metadata.

comment on the above section


2.11 Content linking and associations

The metadata model will include provisions for associating (linking) all manner of assets to any other asset (e.g., associating with a piece of content any type or quantity of 3D models, videos, research papers, book chapters, Web pages, reports, forums, etc.). Allowing content assets in the system to be associated (linked) with any type or number of others asset will enable a rich information system that benefits users, content creators, educators and researchers.

comment on the above section


2.12 Federated authentication and authorization

Security is a top priority for Immersive Education. Security will be built into the Education Grid from the ground up, starting with requirements specifications and design documents. Authentication and authorization are core pillars of security. The Education Grid will support a federated system for authentication and authorization that will enable Immersive Education users to established a trusted identity that "follows" them throughout their usage of the system (i.e., as they engage in learning experiences delivered via the Education Grid). Once authorized for a session, the federated system will permit access to all object authorized for a given user; after logging into the systems users will be able to traverse Immersive Education learning environments without the frustration of having to manage multiple account usernames and passwords, and without having to stop and gain authorization for each learning object visited in a session.

comment on the above section


2.13 Protected learning environments

Immersive Education requires the establishment of learning environments with varying levels of protection. Public environments will impose the fewest restrictions and enable the widest distribution of learning assets and virtual classroom experiences. Private learning environments may also be created with restricted access only to authorized users in order to provide safe learning environments —especially for young children who, for example, should only engage in multi-user collaborations that involve their fellow classmates and their teacher(s).

Protected environments with restrictions on permitted content may also be provided to enable quick and easy means for educators, parents, administrators, and facilitators to control access to categorical ranges of content (c.f., video and entertainment rating systems).

comment on the above section


2.14 Usage metrics

Varying utilization metrics will be required ranging from realtime playback (re-play of an experience in real time), audio/video and image recording and capture, to data reduction mechanisms for quantitative evaluation and assessment. Educators and students alike should have the capability to record and play back educational experiences for purposes of citation, historical records, safety measures, further study and/or assessment purposes. Informed consent shall be obtained in all scenarios where session recording is possible. Additional usage and tracking mechanisms (such as avatar navigation tracking, storing pages of text opened and read, logging video segments watched by the user, etc.), may be provided as completion metrics and for assessment.

comment on the above section


2.15 Content watermarking, hashing and encryption

Content protection measures must be provided for many reasons, the most obvious being usage tracking and content verification (ensuring that the content delivered to an end user is, in fact, the content they should receive). Content producers must have the capability to track usage of their creations for any of a number of reasons ranging from personal satisfaction to receiving compensation from for-profit utilization of their work. Additionally, watermarking content provides protection enabling the blocking of content deemed unsuitable for various classifications of users. Watermarking, hashing and encryption may also facilitate secure distribution of content to end users (an especially important consideration when peer-to-peer delivery mechanisms are employed) by enabling scalable identification, authorization, and secured content delivery services. Support for such features implies that Immersive Education applications may require a degree of certification before being permitted to access the Education Grid.

comment on the above section


2.16 Anti-spoofing mechanisms

The need to permit a wide range of representations (i.e., avatars) for individuals in Immersive Education is self-evident. However, the capability to tie multiple and fanciful avatars to specific users must be provided. The capacity for anonymity may be preserved in some spaces, but in order to create learning environments that are safe, protected and secure anti-spoofing mechanisms must be implemented.

comment on the above section


2.17 Port ranges

A software port is a logical data connection that software applications can use to exchange data directly instead of through a file or temporary storage location. TCP and UDP ports, for example, enable computers to exchange data over the Internet. HTTP (the World Wide Web protocol) data is transmitted via port 80 by default. Formal port designations, such as port 80 for HTTP, facilitate reliable communications and provide network administrators with a mechanism for allowing legitimate network activity while blocking other traffic. Many organizations intentionally block ports that are unknown or unfamiliar, for instance, rendering applications that communicate on such ports unusable (port blocking is often used to prevent file sharing in schools, for instance).

Immersive Education applications are inherently Internet-based, and therefore require routine and reliable access to Education Grid servers hosted on the public Internet. Establishing a formal range of port numbers will facilitate communication between client-side Immersive Education platforms and the Education Grid servers. Formal port ranges also allow network administrators to more easily install, manage, and monitor Immersive Education applications on an organization-wide basis (schools can "unblock" Immersive Education ports to allow these applications to run properly, for example). A range of port numbers may be used to logically partition and organize Education Grid services by assigning specific port numbers to specific services.

Immersive Education ports shall be formally registered with the Internet Assigned Numbers Authority (IANA) (see and

comment on the above section


2.18 Annotations

Annotations enable Immersive Education users to annotate, or take "notes" of, the learning experiences they participate in. Annotations may occur at any time during an Immersive Education experience and may be provided by the user in the form of text, voice recordings, hand-drawn imagery (written words or sketched/drawn images), and/or file attachments. This implies that the Education Grid must support personal end user accounts (services) through which user annotations are stored and mapped to specific aspects of a learning experience. A student, for example, might make annotations at various points in time while taking an Immersive Education modern architecture class. These annotations are stored on the Education Grid in the students personal account; the student can retrieve the annotations at any time and view them within the context of the learning experience or independent of the learning experience.

comment on the above section


2.19 Highly available and reliable

The Education Grid must be highly available and reliable. Users must be able to engage in Immersive Education learning environments and experiences at any time with a reasonable degree of certainty that the system will be fully operational 24x7 (every hour of every day of the week) and also that the system won't crash, freeze or behave in erratic or unpredictable ways. This requirement implies that Education Grid services will be 1) implemented via a redundant and potentially failsafe network, storage and compute infrastructure, and 2) all services will be thoroughly tested and certified before being made available on the production system.

comment on the above section


2.20 Publish and consume pipelines

The Education Grid must support two-way (bi-directional) usage scenarios. Users must be able to consume (use) services provided by the Education Grid while content developers must be able to publish content into the system. End-user platform vendors must therefore have a clearly defined mechanism, process and API for accessing (consuming) Education Grid services while tool vendors must have a similar pipeline for publishing content and services into the system.

comment on the above section



  • Upgrade and unlock interface and controls
  • Social network overlays
  • Standardized units of measurement
  • Voice and application bridges
  • Archiving and preservation
  • Micro-transaction and credit-based economies
  • LMS integration
  • Content Framing


comment on the above section


Conformance Requirements

This section is normative.

Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The keyword "IMPLEMENTATION" refers to any software or software and hardware combination that implements this specification.

Comments and notes not intended as specification material appear as RED TEXT.

TBD: The acronym TBD is used to indicate material "To Be Determined" for which feedback, comments and discussion are requested.


Service Request Processing

Owing to the requirement for secure, stable, reliable and trusted implementations, any implementation of this specification:

  1. may accept service requests only for services defined by and must reject all other service requests.
  2. shall not accept service requests that contain arbitrary code or executable code that does not correspond to services defined by
  3. shall not accept service requests that exceed the specified data payload limit or for which data URIs resolve to a domain other than


comment on the above section


This section is normative.

"Assigned Numbers", RFC 790, J. Postel, September 1981.
Available at:
"Address Allocation for Private Internets", RFC 1918, Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, February 1996.
Available at:
"Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, S. Bradner, March 1997.
Available at:
"URN Syntax", RFC 2141, R. Moats, May 1997.
Available at:
"Administratively Scoped IP Multicast", RFC 2365, D. Meyer, July 1998.
Available at:
"IP Version 6 Addressing Architecture", RFC 2373, R. Hinden, S. Deering, July 1998.
Available at:
"Simple Mail Transfer Protocol", RFC 2821, J. Klensin, April 2001.
Available at:
"Internet Message Format", RFC 2822, P. Resnick, April 2001.
Available at:
"Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, T. Berners-Lee, R. Fielding, L. Masinter, January 2005.
Available at:
"A URN Namespace for the Media Grid", RFC XXXX, XXXX 2006.
Available at: (this RFC is pending publication)

comment on the above section

Grid Institute Home Page
Copyright Statement and Legal Notice.