27 | | |
28 | | Approach: |
| 27 | **Provide broad data gathering, analysis and archival capability that is sufficient for scientific mission, operations, and success of the infrastructure. |
| 28 | |
| 29 | **Remove the burden on researcher to become a system and network measurement infrastructure expert so that researcher can better focus on the science in the experiments |
| 30 | |
| 31 | **Follow defined I&M architecture |
| 32 | |
| 33 | Approach: |
| 34 | ** Two large I&M projects (GIMI and GEMINI) approved from Sol 3, which include groups that have provided OML, INSTOOLS and LAMP/perfSONAR tools |
| 35 | |
| 36 | **SOWS for remaining Year 3 of Sol 2 I&M projects focused on key topics that need to be resolved |
| 37 | |
| 38 | Architecture: |
55 | | Requires XML messaging service, with pub/sub, in public IP space [[BR]] |
56 | | |
57 | | Introduces portal service, with: OML Server, for collection; Results Service, for presentation; measurement orchestration service using OMF; documentation service to create and edit MDOD. Can portal be shared with GEMINI project? [[BR]] |
58 | | |
59 | | Introduces iRODS service for user workspace and archive. Can GEMINI use iRODS? Can iRODS serve as registry for MDOD? [[BR]] |
| 65 | *Requires XML messaging service, with pub/sub, in public IP space [[BR]] |
| 66 | |
| 67 | *Introduces portal service, with: OML Server, for collection; Results Service, for presentation; measurement orchestration service using OMF; documentation service to create and edit MDOD. Can portal be shared with GEMINI project? [[BR]] |
| 68 | |
| 69 | *Introduces iRODS service for user workspace and archive. Can GEMINI use iRODS? Can iRODS serve as registry for MDOD? [[BR]] |
127 | | Assuming LAMP/perfSONAR tools, develop a plan to evaluate the performance of today’s GENI IP backbone and access networks, using persistent or temporary “infrastructure measurement slices”, and utilizing existing perSONAR nodes in I2 and/or other networks. [[BR]] |
128 | | |
129 | | Define a procedure for evaluating the performance of GENI’s backbone and access networks when carrying L2 VLANs; start with the existing IP measurement tools including in the LAMP/perfSONAR tools, but consider tools that are specialized for evaluating the performance of L2 networks. [[BR]] |
130 | | |
131 | | Define a procedure for evaluating the performance of GENI’s backbone and access networks when using OpenFlow (e.g., “Tango GENI”); consider how to monitor the performance of OF networks, and introducing new specialized tools. [[BR]] |
| 137 | *Assuming LAMP/perfSONAR tools, develop a plan to evaluate the performance of today’s GENI IP backbone and access networks, using persistent or temporary “infrastructure measurement slices”, and utilizing existing perSONAR nodes in I2 and/or other networks. [[BR]] |
| 138 | |
| 139 | *Define a procedure for evaluating the performance of GENI’s backbone and access networks when carrying L2 VLANs; start with the existing IP measurement tools including in the LAMP/perfSONAR tools, but consider tools that are specialized for evaluating the performance of L2 networks. [[BR]] |
| 140 | |
| 141 | *Define a procedure for evaluating the performance of GENI’s backbone and access networks when using OpenFlow (e.g., “Tango GENI”); consider how to monitor the performance of OF networks, and introducing new specialized tools. [[BR]] |
143 | | Work with the GENI community to define extensions to the “descriptor” that would locate and describe objects beyond “measurement data objects” associated with an experiment, such as scripts, images, etc. [[BR]] |
144 | | |
145 | | Modify your tools to create, gather and forward “descriptors”, that could locate and describe all objects associated with an experiment; demonstrate how “descriptors” can be automatically created. [[BR]] |
146 | | |
147 | | Work with the GENI I&M community to define a modified “descriptor” that would provide a standardized GENI “resource event record”; these records could describe events such as assignments, faults or errors. [[BR]] |
148 | | |
149 | | Add modules to your tools to create, gather and forward “resource event records”, that when logged could fully describe the sequence of an experiment. [[BR]] |
| 153 | *Work with the GENI community to define extensions to the “descriptor” that would locate and describe objects beyond “measurement data objects” associated with an experiment, such as scripts, images, etc. [[BR]] |
| 154 | |
| 155 | *Modify your tools to create, gather and forward “descriptors”, that could locate and describe all objects associated with an experiment; demonstrate how “descriptors” can be automatically created. [[BR]] |
| 156 | |
| 157 | *Work with the GENI I&M community to define a modified “descriptor” that would provide a standardized GENI “resource event record”; these records could describe events such as assignments, faults or errors. [[BR]] |
| 158 | |
| 159 | *Add modules to your tools to create, gather and forward “resource event records”, that when logged could fully describe the sequence of an experiment. [[BR]] |
162 | | Prototype and demonstrate a GENI I&M “measurement orchestration service”, based on the ORBIT Management Framework (OMF) software modules provided by NICTA, including the Experiment Controller (EC) and the Resource Controller (RC). [[BR]] |
163 | | |
164 | | Prototype and demonstrate using your pub/sub capability to transport and distribute standardized GENI “resource event records”, as defined by the NetKarma project. [[BR]] |
| 172 | *Prototype and demonstrate a GENI I&M “measurement orchestration service”, based on the ORBIT Management Framework (OMF) software modules provided by NICTA, including the Experiment Controller (EC) and the Resource Controller (RC). [[BR]] |
| 173 | |
| 174 | *Prototype and demonstrate using your pub/sub capability to transport and distribute standardized GENI “resource event records”, as defined by the NetKarma project. [[BR]] |