Changes between Initial Version and Version 1 of ShadowNet-Report-August-2013

Timestamp:

08/27/13 16:53:23 (11 years ago)

Author:

griff@netlab.uky.edu

Comment:

--

ShadowNet-Report-August-2013

@@ +1 @@
+[[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 ===
+