wiki:ShadowNet-Report-August-2013

GENI Shadownet Project Status Report

Period: Post GEC 17 Report

I. Major accomplishments

The following highlights our accomplishments during the last reporting period.

A. Milestones achieved

All required milestones have been completed. At this point our efforts have focused on enhancements and improved interoperability with other tools and services. Two major accomplishements this reporting period include:

  • support for ExoGENI Racks, and
  • integration with the GENI Portal.

B. Deliverables made

  • Continued to modify and enhance our instrumentation and measurement code and the GENI Desktop. The updated code is regularly contributed to the GEMINI repositories.

II. Description of work performed during last quarter

The following provides a description of the progress made during the last reporting period.

A. Activities and findings

During this reporting period we made significant progress in three primary areas; namely GENI Rack support, GENI Portal integration, and GENI Desktop enhancements.

First, we continued to work with the groups at Utah and the GPO to further integrate our InstaGENI rack into GENI and the GENI Openflow network. As part of this work, we performed extensive testing of the rack, using it almost exclusively in all of our experimentation with the GENI desktop and GEMINI. In addition to working with our InstaGENI rack (and the other InstaGENI racks that have been coming online), we also enhanced our instrumentation and measurement code to work with ExoGENI racks. Because there are significant and fundamental differences between InstaGENI and ExoGENI, porting our code to ExoGENI was a challenge and involved close cooperation with the ExoGENI team. Different RSPEC formats/extensions, the node OS used, software preinstalled on nodes, internal and external IP address assignments (or the lack thereof), the ways for the code on an experimental node to discover its context, and other differences made porting to the ExoGENI environment non-trivial. Despite these challenges, we now have an intial version working that demonstrates basic interoperability with ExoGENI racks. There are still several issues to be addressed, but users of ExoGENI slices should now be able to leverage the GENI Desktop/GEMINI tools and interfaces.

Second, we worked with the GENI portal team to provide interoperability between the GENI Portal and the GENI Desktop. A key goal here was to provide autologin of portal users into the GENI Desktop. The key issue, which is a well-known issue, is the need for tools to "speak as" a user, rather than "speak for" a user. Consequently, the GENI Desktop needs to use the user's credentials to make GENI AM API calls and act on the user's behalf. To address this issue, we worked with the Portal team to develop a protocol between that would pass the needed information from the GENI Portal to the GENI Desktop. In the future, the plan is to pass "speaks for" credentials. It should be noted, that this exchange of information was also combined with the ability to seamlessly move back and forth between the GENI Portal web pages to GENI Desktop web pages. We also changed the GENI Desktop login page to redirect to the GENI Portal login page so that GENI Portal account information could be used to login to the GENI Desktop. After working through many challenges with the Portal team and making adjustments to both the GENI Portal and GENI Desktop, users are now able to login to the GENI Portal and then move freely between the two tools.

The interoperability between the GENI Desktop and the GENI Portal was complicated by the fact that there is currently no standard for slice authorities. The lack of a common interface to slice authorities makes it difficult for tools like the GENI Desktop to query the slice authority to find information about a slice -- information needed to list slices and provide a graphical image of the topology. At present, the GENI Desktop is able to retrieve this infomation using a ProtoGENI-like SA API, but this does not leverage all the features of the GENI Portal SA, nor will it work with SAs that do not support these APIs. A common SA API would clearly help to facilitate better interoperability.

Third, we continued to enhance the GENI Desktop, making improvements to its look-and-feel, functionality, and extensibility. We also refactored its code to make it more robust to failures, and to make it easier to write new modules for the Desktop. In particular, we developed an initial prototype of a GENI Desktop module that hopefully could be used by experimenters in the future to write their own extensions to the GENI Desktop. As part of the change to the look-and-feel, we completely redesigned the entry page which lists the slices. The goal of our redesign was to be able to extend the GENI Desktop abstraction of "select and then apply an operation" to slices as well. Users can now select one or more slices and then apply an operation to those slices such as extend the lifetime of the slice(s), instrumentize the slice(s), get the status of the slice(s), or delete the slice(s). We have already found these features to be very helpful in our own experimentation and testing of the GENI Desktop.

We demonstrated the new GENI Desktop system and its integration with ExoGENI and the GENI Portal at GEC 17. We also gave a presentation on the GENI Desktop to students at the Second GENI Research and Educational Experiment Summer Camp (GREE-SC 2013). In both conferences/workshops we gave a hands-on tutorial that first introduced the concepts and abstractions underlying the GENI Desktop, and then presented the attendees with a set of tasks to complete using the GENI Desktop to help strengthen their understanding and ability to utilize the various features of the GENI Desktop.

As in the past, we continued to manage and operate the Juniper routers that comprise the Shadownet aggregate, making these resources available to users for use in their experiments.

B. Project participants

The following individuals are involved with the project in one way or another:

  • Jim Griffioen - Project PI (Kentucky)
  • Zongming Fei - Project Co-PI (Kentucky)
  • Kobus van der Merwe - Project Co-PI (was AT\&T, now at Utah)
  • Eric Boyd - Subcontract Lead (Internet2)
  • Brian Cashman - Network Planning Manager (Internet2)
  • Lowell Pike - Network administrator (Kentucky)
  • Hussamuddin Nasir - Technician/Programmer (Kentucky)
  • Charles Carpenter - Researcher/Programmer (Kentucky)
  • Jeremy Reed - Research Assistant (Kentucky)
  • Emmanouil Mavrogiorgis - Research Staff (AT\&T)

C. Publications (individual and organizational)

The following publication describes a network hypervisor service that was an outgrowth of our work on GENI and automated slice setup.

  • Network Hypervisors: Managing the Emerging SDN Chaos, Shufeng Huang, James Griffioen, International Conference on Computer Communications and Networks (ICCCN 2013) Track on Network Architectures and Clean-Slate Designs (NACSD), July 30 - August 2, 2013

D. Outreach activities

  • Jim Griffioen and Hussamuddin Nasir (together with colleagues from Indiana and Utah) gave a demonstration and tutorial at GEC 17 about InstaGENI, the GENI Desktop and the GEMINI I\&M system.
  • We also presented during the demo session at GEC 17 showing the latest version of the GENI Desktop and its features.

E. Collaborations

Most of our collaborations have been with the Shadownet team. It involves participants from Kentucky, Utah (previously at AT\&T), and Internet2, but we have also collaborated closely with our InstaGENI and perfSONAR/LAMP/GEMINI colleagues.

F. Other Contributions

Last modified 6 years ago Last modified on 08/27/13 16:53:23