= GEMINI v1.1 Definition = Based on GEMINI design reviews on 9/28 and 10/5, GEMINI v1.1 to be released at GEC15 is defined to: a) Continue to support GEMINI tools in v1.0 that are based on LAMP and INSTOOLS modules, to provide (respectively) active network and passive host measurements. b) Introduce the new GEMINI architecture with the BLiPP Measurement Point and the Measurement Store (MS) modules, to provide an alternate way to gather passive host measurements. c) Use the current rspec extension approach to load and enable tools on nodes: active network measurements (LAMP modules), Type-1 passive host measurements (INSTOOLS modules) and Type-2 passive host measurements (BLiPP and MS modules). d) Use Periscope installed on GN to observe Type-2 passive host measurements. e) Include NewUNIS operational service (IU) for use with BLiPP and MS modules; retain OldUNIS operational service (IU) to support legacy modules; modify instrumentation script and configuration GUI to push configuration data to both OldUNIS and NewUNIS. f) Introduce flexible Authentication and Authorization (AA) between new modules (BLiPP and MS) and NewUNIS. g) Modify GEMINI Portal to display data from all types of measurements, and to utilize NewUNIS for storing configuration data. h) Support these operational services: NewUNIS (IU); OldUNIS (IU); ProxyCertGenerator (IU); LAMP CA (IU); GEMINI Portal (UK); iRODS (UK) i) Operate on these target aggregates: protoGENI sites (e.g., Utah or UK) and InstaGENI racks (e.g., Utah). j) Support installing both MPs and GN on InstaGENI VMs, in addition to bare-metal servers. k) Provide a set of "usable tools” for experimenters, to be presented in a tutorial at GEC15. l) Use the reference workflow as a guide for GEC15 tutorial. m) Show how to setup slice in GEC15 tutorial using FLACK to formulate request rspec, and OMNI to obtain resources via GENI AM API. n) Include a realistic reference experiment in the GEC15 tutorial, and include a convenient orchestration method. o) Enable passive host measurements and basic active network measurements (i.e., ping) for the duration of the experiment run, and arrange for experimenter to view measurements in real time, so that they can verify that experiment run is proceeding as expected. p) Enable active network measurements (i.e., iperf) for a short time at the start of the experiment run, and arrange for experimenter to view measurements in real time, so that they can verify the continuity of their slice, and that it can handle the expected traffic. q) Finally, orchestrate the reference experiment, to generate traffic and collect desired measurements from within the experiment; alternately, use active network measurements (i.e., iperf) to generate and measure traffic that flows through reference experiment topology. r) After experiment run finishes, arrange for experimenter to format and view measurements that have been collected during run, to verify that experiment has been successfully completed, and to study results. s) After experiment finishes, allow experimenter to push measurements that have been collected during run into the iRODS storage service; later, allow them to retrieve these measurements and view them again. Note: this is currently limited to Type-1 passive host measurements (INSTOOLS modules). t) Allow experimenter to store and retrieve various types of experiment artifacts (i.e., scripts) using the iRODS storage service.