Changes between Initial Version and Version 1 of DigitalObjectRegistry-Q209-status


Ignore:
Timestamp:
05/25/10 17:12:38 (13 years ago)
Author:
jtaylor@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DigitalObjectRegistry-Q209-status

    v1 v1  
     1[[PageOutline]]
     2
     3= DigitalObjectRegistry Project Status Report =
     4
     5Period: Q209
     6== I. Major accomplishments ==
     7The scope of work on this project is to adapt the Handle System and/or the CNRI
     8Digital Object Registry to create a clearinghouse registry for principals, slices,
     9and/or components in at least one GENI Spiral 1 control framework, capable of
     10supporting limited operations in Year 1. We will also analyze ways in which the
     11Handle System and/or a Digital Object Registry could be used to identify and
     12register GENI software, including experimenter’s tools, test images and
     13configurations, and test results. Finally, we will define the operational, scaling,
     14security, and management requirements, plus recommended design approaches, for
     15implementing GENI clearinghouse and software registry services.
     16
     17During this quarter, we continued our collaboration with the ProtoGENI group to
     18federate the ProtoGENI clearinghouse records into the proposed GENI Federated
     19Clearinghouse (GFC), which is based on our digital object registry technology.
     20Additionally, we began collaboration with the Million Node GENI group to federate
     21their project records into the GFC, normalized the GFC data model to support the
     22two federates (ProtoGENI and Million Node GENI), defined security requirements
     23for implementing a clearinghouse in GENI, shared a few ideas in the control
     24framework mailing list, completed two milestones, and defined the scope of the
     25demo we are planning to present at the GEC5 in Seattle.
     26=== A. Milestones achieved ===
     27We analyzed the ProtoGENI clearinghouse design and
     28submitted our design of a GENI‐wide usable federated clearinghouse, aka the GENI
     29Federated Clearinghouse (GFC), to the GPO on May 12th, 2009. Supporting the goals
     30and requirements that the GPO and the cluster members have for a clearinghouse
     31while still being interoperable with the data sets and process flows across the
     32clusters was one of our main goals while designing the GFC. We will begin
     33aggregating the ProtoGENI and Million Node GENI clearinghouse records shortly.
     34
     35We also submitted our review and requirements from a security standpoint to build
     36and deploy a clearinghouse in GENI to the GPO on May 29th, 2009. In addition to
     37identifying the security challenges GENI is currently facing, the submitted paper also
     38highlights our proposed solution to the stated problems. To quote one, we proposed
     39a solution to make the servers/services in GENI free from managing a trust store of
     40(X509) certificates at times of new user additions and existing user revocations. Our
     41plan is to integrate our solution with the GFC and demonstrate the proposed
     42capability.
     43
     44Our project was initially part of the “pick one” category. During this quarter, we
     45joined ProtoGENI cluster.
     46
     47=== B. Deliverables made ===
     48During this quarter, we submitted both our GFC design and the security requirements and recommendation documents to the GPO
     49
     50== II. Description of work performed during last quarter ==
     51
     52=== A. Activities and findings ===
     53As described in the last quarterly report, we continue to evaluate the high‐level
     54designs and requirements for GENI principals, components, and slice registries to
     55determine how to leverage existing technologies, such as the Handle System and the
     56digital object repository/registry system, to best create a common GENI
     57clearinghouse registry.
     58
     59ProtoGENI has implemented a clearinghouse with features that are suitable to their
     60Emulab based framework. In our evaluation, we identified the commonality that
     61exists between the GPO requirements and the ProtoGENI implementation, and also
     62identified the assumptions and points where the two differ. We then designed a
     63preliminary version of a clearinghouse that posits a normalized data model
     64providing features that we believe cut across all the clusters. Our goal is to define a
     65common clearinghouse model to perform federation of clearinghouse records GENIwide.
     66Our design document, available on our project wiki page, will continue to be
     67updated as and when our design undergoes any revision to keep up with any new
     68requirements, as driven by experience and adding additional federates.
     69
     70Our data model includes specification of the various records that a clearinghouse
     71will hold such as that of a user, resource, component, aggregate, slice, sliver, and so
     72on. We also capture the relationship between those records and any dependencies
     73involved. We have also designed registry interfaces to each of those records at an
     74abstract level, with the goal of having those abstract interfaces applicable to any
     75new federate participating in our federation. The specific details of application level
     76protocols and interfaces are left to implementation decisions as driven by the
     77requirements of individual federates joining our effort.
     78
     79In our last report, we described some of the improvements that we would pursue in
     80our federated clearinghouse design, such as adding search capability to the
     81clearinghouse, providing unique and resolvable identifiers for the records, and so
     82on. Additionally, upon further evaluation of the ProtoGENI clearinghouse, and for
     83that matter, other clearinghouses in GENI, we concluded that the notion of RSpec
     84needs refinement to enable interoperability across GENI. ProtoGENI uses RSpec as
     85an exchangeable data structure that researchers and component managers use to
     86negotiate and decide on the resources those researchers would need to run their
     87experiments. Additionally, the RSpec data structure is also used to describe
     88individual resources that are grouped together into components. While utilizing a
     89single data structure to fit the needs of multiple processes (namely, resource
     90negotiation and component descriptions) is an optimization of a single specification,
     91it poses potential confusion and possible variant interpretations of the specification
     92by the various parties involved in GENI. Further, description of those resources in
     93isolation makes difficult querying for and resolving to those resources in the
     94ProtoGENI implementation. The ability to consistently identify a particular resource
     95and reason about that resource in a uniform manner is necessary for researchers
     96across GENI to use those resources in an interoperable fashion. That is, resources
     97should be uniquely identified, and consistently defined, with a set taxonomy, across
     98GENI to enable experiments to be run on resources hosted across various clusters.
     99In our GFC design, we define an extensible specification for resources, which have
     100identifiers that resolve to resource descriptions, status, governing components, and
     101other attributes. We have, however, left open the taxonomy‐based description for
     102the future. Currently, this attribute is a placeholder that captures whatever formats
     103and methods individual organizations use to describe resources, but going forward
     104we will have to normalize the specification. We have started with an aggregation of
     105two (ProtoGENI and Million Node GENI), and each added federate will improve the
     106chances of producing a truly interoperable specification. Having completed the
     107model, we will begin aggregating the records from both of the federates and plan on
     108providing client tools and utilities for those federates to use and thus integrate with
     109our GFC.
     110
     111On the security front, we identified what we believe are shortcomings in the present
     112GENI practices. In the current approach, the responsibility of maintaining security
     113and trust credentials is redundantly placed in multiple places. For example, user
     114certificates (with public keys) and the entities who signed those user certificates are
     115not only maintained by appropriate parties (users and signing entities,
     116respectively), but also by the servers that need to authenticate and trust potential
     117users in the form of trust stores. Those trust stores are updated with each new user
     118addition or revocation. Further, those trust stores, managed by multiple servers,
     119must always be in sync with each other across all of GENI in order to ward off
     120intruders. We propose that the trust store for GENI should be maintained by a
     121highly scalable and distributed system, and authentication servers should access a
     122required certificate from that system in a dynamic fashion. A direct result would be
     123that the management, revocation, and synchronization aspects of certificates would
     124be managed under a single consistent system. In addition to being distributed, user
     125certificates in such a system could be managed in such a manner that administration
     126on those records could be performed by multiple entities. We propose to use the
     127Handle System for this requirement, the complete details of our requirement is
     128made available on our project wiki page.
     129
     130On a related note, we participated in an interesting thread started by Max Ott in the
     131control framework working group on the topic of the need for GIDs. Most of those
     132participating in the thread appeared to agree with our notion of making the
     133identifiers non‐semantic and persistent. The topic was continued in one of our biweekly
     134calls. We look to further discussion of this at the GEC5 in Seattle.
     135
     136Finally, we are planning to demonstrate the functionality of our proposed GENI
     137Federated Clearinghouse at the GEC5. We will demonstrate a data model for the
     138clearinghouse records (user, resource, component, aggregate, sliver, slice, and
     139corresponding manager records) to give an idea of how we will combine the GPO
     140and cluster members' goals for the clearinghouse. We will also highlight the
     141scalability of the implemented system. The demonstration will include
     142dissemination of the ProtoGENI clearinghouse information in real‐time using a web
     143interface. We also hope to show how the Million Node GENI project would be
     144incorporated into the GFC.
     145
     146Additional capabilities, such as how end users can search specific RSpec elements to
     147discover resources will also be demonstrated. Finally, we plan to demonstrate the
     148proposed security model that provides "freedom from the CRLs". The proposed
     149security model is implemented using the PKI capability embedded in the Handle
     150System.
     151=== B. Project participants ===
     152CNRI has discussed its project with a number of other GENI participants, but all
     153work done this quarter was done by CNRI alone or with the cooperation of
     154ProtoGENI and Million Node GENI personnel. Names and email addresses of CNRI
     155participants are available on the GENI wiki page for the project. Robert Ricci and
     156Leigh Stoller from ProtoGENI and Justin Cappos from Million Node GENI project
     157collaborated with us during this quarter.
     158=== C. Publications (individual and organizational) ===
     159No publications were produced this quarter. CNRI produced the GENI Federated
     160Clearinghouse design document and the GENI Security Requirements and Proposed
     161Solution document. Those documents are available on the GENI wiki page for the
     162project.
     163=== D. Outreach activities ===
     164CNRI, specifically project PI Laurence Lannom, Giridhar Manepalli and Christophe
     165Blanchi, attended the technical discussions in the ProtoGENI bi‐weekly teleconference
     166and also participated in various GENI mailing lists. We are actively
     167collaborating with ProtoGENI and Million Node GENI project members to get the
     168GENI Federated Clearinghouse into production.
     169=== E. Collaborations ===
     170
     171=== F. Other Contributions ===