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

Timestamp:

05/25/10 17:12:38 (14 years ago)

Author:

jtaylor@bbn.com

Comment:

--

DigitalObjectRegistry-Q209-status

@@ +1 @@
+[[PageOutline]]
+
+= DigitalObjectRegistry Project Status Report = 
+
+Period: Q209
+== I. Major accomplishments ==
+The scope of work on this project is to adapt the Handle System and/or the CNRI
+Digital Object Registry to create a clearinghouse registry for principals, slices,
+and/or components in at least one GENI Spiral 1 control framework, capable of
+supporting limited operations in Year 1. We will also analyze ways in which the
+Handle System and/or a Digital Object Registry could be used to identify and
+register GENI software, including experimenter’s tools, test images and
+configurations, and test results. Finally, we will define the operational, scaling,
+security, and management requirements, plus recommended design approaches, for
+implementing GENI clearinghouse and software registry services.
+
+During this quarter, we continued our collaboration with the ProtoGENI group to
+federate the ProtoGENI clearinghouse records into the proposed GENI Federated
+Clearinghouse (GFC), which is based on our digital object registry technology.
+Additionally, we began collaboration with the Million Node GENI group to federate
+their project records into the GFC, normalized the GFC data model to support the
+two federates (ProtoGENI and Million Node GENI), defined security requirements
+for implementing a clearinghouse in GENI, shared a few ideas in the control
+framework mailing list, completed two milestones, and defined the scope of the
+demo we are planning to present at the GEC5 in Seattle.
+=== A. Milestones achieved ===
+We analyzed the ProtoGENI clearinghouse design and
+submitted our design of a GENI‐wide usable federated clearinghouse, aka the GENI
+Federated Clearinghouse (GFC), to the GPO on May 12th, 2009. Supporting the goals
+and requirements that the GPO and the cluster members have for a clearinghouse
+while still being interoperable with the data sets and process flows across the
+clusters was one of our main goals while designing the GFC. We will begin
+aggregating the ProtoGENI and Million Node GENI clearinghouse records shortly.
+
+We also submitted our review and requirements from a security standpoint to build
+and deploy a clearinghouse in GENI to the GPO on May 29th, 2009. In addition to
+identifying the security challenges GENI is currently facing, the submitted paper also
+highlights our proposed solution to the stated problems. To quote one, we proposed
+a solution to make the servers/services in GENI free from managing a trust store of
+(X509) certificates at times of new user additions and existing user revocations. Our
+plan is to integrate our solution with the GFC and demonstrate the proposed
+capability.
+
+Our project was initially part of the “pick one” category. During this quarter, we
+joined ProtoGENI cluster.
+
+=== B. Deliverables made ===
+During this quarter, we submitted both our GFC design and the security requirements and recommendation documents to the GPO
+
+== II. Description of work performed during last quarter ==
+
+=== A. Activities and findings ===
+As described in the last quarterly report, we continue to evaluate the high‐level
+designs and requirements for GENI principals, components, and slice registries to
+determine how to leverage existing technologies, such as the Handle System and the
+digital object repository/registry system, to best create a common GENI
+clearinghouse registry.
+
+ProtoGENI has implemented a clearinghouse with features that are suitable to their
+Emulab based framework. In our evaluation, we identified the commonality that
+exists between the GPO requirements and the ProtoGENI implementation, and also
+identified the assumptions and points where the two differ. We then designed a
+preliminary version of a clearinghouse that posits a normalized data model
+providing features that we believe cut across all the clusters. Our goal is to define a
+common clearinghouse model to perform federation of clearinghouse records GENIwide.
+Our design document, available on our project wiki page, will continue to be
+updated as and when our design undergoes any revision to keep up with any new
+requirements, as driven by experience and adding additional federates.
+
+Our data model includes specification of the various records that a clearinghouse
+will hold such as that of a user, resource, component, aggregate, slice, sliver, and so
+on. We also capture the relationship between those records and any dependencies
+involved. We have also designed registry interfaces to each of those records at an
+abstract level, with the goal of having those abstract interfaces applicable to any
+new federate participating in our federation. The specific details of application level
+protocols and interfaces are left to implementation decisions as driven by the
+requirements of individual federates joining our effort.
+
+In our last report, we described some of the improvements that we would pursue in
+our federated clearinghouse design, such as adding search capability to the
+clearinghouse, providing unique and resolvable identifiers for the records, and so
+on. Additionally, upon further evaluation of the ProtoGENI clearinghouse, and for
+that matter, other clearinghouses in GENI, we concluded that the notion of RSpec
+needs refinement to enable interoperability across GENI. ProtoGENI uses RSpec as
+an exchangeable data structure that researchers and component managers use to
+negotiate and decide on the resources those researchers would need to run their
+experiments. Additionally, the RSpec data structure is also used to describe
+individual resources that are grouped together into components. While utilizing a
+single data structure to fit the needs of multiple processes (namely, resource
+negotiation and component descriptions) is an optimization of a single specification,
+it poses potential confusion and possible variant interpretations of the specification
+by the various parties involved in GENI. Further, description of those resources in
+isolation makes difficult querying for and resolving to those resources in the
+ProtoGENI implementation. The ability to consistently identify a particular resource
+and reason about that resource in a uniform manner is necessary for researchers
+across GENI to use those resources in an interoperable fashion. That is, resources
+should be uniquely identified, and consistently defined, with a set taxonomy, across
+GENI to enable experiments to be run on resources hosted across various clusters.
+In our GFC design, we define an extensible specification for resources, which have
+identifiers that resolve to resource descriptions, status, governing components, and
+other attributes. We have, however, left open the taxonomy‐based description for
+the future. Currently, this attribute is a placeholder that captures whatever formats
+and methods individual organizations use to describe resources, but going forward
+we will have to normalize the specification. We have started with an aggregation of
+two (ProtoGENI and Million Node GENI), and each added federate will improve the
+chances of producing a truly interoperable specification. Having completed the
+model, we will begin aggregating the records from both of the federates and plan on
+providing client tools and utilities for those federates to use and thus integrate with
+our GFC.
+
+On the security front, we identified what we believe are shortcomings in the present
+GENI practices. In the current approach, the responsibility of maintaining security
+and trust credentials is redundantly placed in multiple places. For example, user
+certificates (with public keys) and the entities who signed those user certificates are
+not only maintained by appropriate parties (users and signing entities,
+respectively), but also by the servers that need to authenticate and trust potential
+users in the form of trust stores. Those trust stores are updated with each new user
+addition or revocation. Further, those trust stores, managed by multiple servers,
+must always be in sync with each other across all of GENI in order to ward off
+intruders. We propose that the trust store for GENI should be maintained by a
+highly scalable and distributed system, and authentication servers should access a
+required certificate from that system in a dynamic fashion. A direct result would be
+that the management, revocation, and synchronization aspects of certificates would
+be managed under a single consistent system. In addition to being distributed, user
+certificates in such a system could be managed in such a manner that administration
+on those records could be performed by multiple entities. We propose to use the
+Handle System for this requirement, the complete details of our requirement is
+made available on our project wiki page.
+
+On a related note, we participated in an interesting thread started by Max Ott in the
+control framework working group on the topic of the need for GIDs. Most of those
+participating in the thread appeared to agree with our notion of making the
+identifiers non‐semantic and persistent. The topic was continued in one of our biweekly
+calls. We look to further discussion of this at the GEC5 in Seattle.
+
+Finally, we are planning to demonstrate the functionality of our proposed GENI
+Federated Clearinghouse at the GEC5. We will demonstrate a data model for the
+clearinghouse records (user, resource, component, aggregate, sliver, slice, and
+corresponding manager records) to give an idea of how we will combine the GPO
+and cluster members' goals for the clearinghouse. We will also highlight the
+scalability of the implemented system. The demonstration will include
+dissemination of the ProtoGENI clearinghouse information in real‐time using a web
+interface. We also hope to show how the Million Node GENI project would be
+incorporated into the GFC.
+
+Additional capabilities, such as how end users can search specific RSpec elements to
+discover resources will also be demonstrated. Finally, we plan to demonstrate the
+proposed security model that provides "freedom from the CRLs". The proposed
+security model is implemented using the PKI capability embedded in the Handle
+System.
+=== B. Project participants ===
+CNRI has discussed its project with a number of other GENI participants, but all
+work done this quarter was done by CNRI alone or with the cooperation of
+ProtoGENI and Million Node GENI personnel. Names and email addresses of CNRI
+participants are available on the GENI wiki page for the project. Robert Ricci and
+Leigh Stoller from ProtoGENI and Justin Cappos from Million Node GENI project
+collaborated with us during this quarter.
+=== C. Publications (individual and organizational) ===
+No publications were produced this quarter. CNRI produced the GENI Federated
+Clearinghouse design document and the GENI Security Requirements and Proposed
+Solution document. Those documents are available on the GENI wiki page for the
+project.
+=== D. Outreach activities ===
+CNRI, specifically project PI Laurence Lannom, Giridhar Manepalli and Christophe
+Blanchi, attended the technical discussions in the ProtoGENI bi‐weekly teleconference
+and also participated in various GENI mailing lists. We are actively
+collaborating with ProtoGENI and Million Node GENI project members to get the
+GENI Federated Clearinghouse into production.
+=== E. Collaborations ===
+
+=== F. Other Contributions ===