[[PageOutline]]

= 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 ===