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

Timestamp:

08/23/11 23:06:08 (13 years ago)

Author:

griff@netlab.uky.edu

Comment:

--

ShadowNet-Report-August-2011

@@ +1 @@
+[[PageOutline]]
+
+= GENI Shadownet Project Status Report = 
+
+Period: Post GEC 11 Report
+
+== I. Major accomplishments ==
+
+The following highlights our accomplishments
+during the last reporting period.
+
+=== A. Milestones achieved ===
+
+During the last reporting period we achieved the following milestones:
+ * (milestone s3.c) We took a major step toward making Juniper routers 
+   accessible
+   to GENI users by integrating our Shadownet Component Manager into the
+   ProtoGENI control framework so that the logical routers on the Juniper
+   will appear as resourses available for users to use.   Our next step is to
+   integrate our instrumentation tools with the Juniper routers so that
+   monitoring/measurement data collection is setup automatically -- in our
+   previous demos this was a manual process.
+ * (milestone s3.d) We updated our Shadownet web pages with information
+   about the system and support contacts for the Shadownet Aggregate.
+ * (milestone s3.e) We have an initial design and implementation of
+   our software that works in conjunction with the perfSONAR tools.
+
+=== B. Deliverables made ===
+
+ * Routers have been installed and are being operated in all four
+   Shadownet locations: Kansas City, Salt Lake City, Washington DC, and
+   Atlanta.
+
+== 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 ===
+
+Our work this past quarter focused on the problem of integrating Shadownet
+into the ProtoGENI network with the intent of making the GENI Shadownet 
+resources available via the ProtoGENI interfaces and APIs.  Starting with the
+standalone GENI Shadownet CM (component manager) 
+that we developed earlier, we made modifications in order to integrate
+it into the ProtoGENI architecture, enabling it to accept
+ProtoGENI credentials and interact with ProtoGENI users via the standard
+ProtoGENI API calls.  We developed our initial version of the system in a
+test environment in order to evaluate our design and implementation.  
+Recently, we moved our GENI Shadownet CM from the test
+environment to the production ProtoGENI network.  We have now integrated our 
+CM with the ProtoGENI Clearinghouse which means that all 
+the resources advertised by our component manager automatically become visible
+to GENI users and can be allocated by them into their slices.  For example,
+users of the ProtoGENI FLACK client are now able to see the Shadownet CM 
+and any resources that it has been configured to advertise.
+
+One of the key issues we have been working through is the issue of how to 
+connect the Juniper's logical router interfaces to other ProtoGENI routers 
+and end systems (say nodes at Kentucky or Utah).
+Because these resources are often managed by other CMs, connecting to these
+resources involves "stitching" together resources from the Shadownet CM
+with end system nodes advertised by, say, the Utah or Kentucky CMs.
+While there has been siginificant progress this past year in regards
+to stitching in GENI, it is still a work in progress with several limitations.
+Given the fact that stitching is not yet mature, we have begun to look at
+other options for connecting our logical routers to other GENI resources.
+We are currently exploring a solution based on GRE tunnels since GRE tunnels
+represent a "least common denominator" across a wide range of GENI resources.
+Ideally, one would like 
+each logical router to have its own unique, 
+routable, IP address.  However, as of this writing, we do not have
+enough IP addresses to give away to logical routers.
+Consequently, we have been looking into ways to run GRE tunnels over a single
+shared IP address used by the physical router.  We have had some success
+doing this in a test environment, but are still working on getting this
+working in the more general ProtoGENI environment.  In the meantime, we have
+initiated  discussions with our colleagues at Internet 2 about obtaining
+additional IP addresses which would greatly help, and we continue to be
+involved in the stitching discussions.
+
+We also made significant enhancements to our GENI Monitoring Portal (GMP)
+interface and 
+integrated the portal interface with the ProtoGENI FLACK graphical user 
+interface so that users can get directly to the portal from the FLACK
+interface.  The portal shows the location of the resources that comprise a 
+slice on a map and provides a link for users to immediately view measurement
+data being gathered at nodes and links as well as providing a link that will 
+take the user to the measurement controller associated with a set of
+resources.  Part of our enhancements have focused on redesigning the portal to
+be able to interact with the measurement controllers for the shadownet logical
+routers.  Our current plan is to allocate multiple measurement controllers, 
+one for each of the shadownet routers to be monitored.  This differs from the 
+single MC per aggregate approach we have used to-date, but enables us to 
+localize data communication so that it does not leave the Internet 2 backbone
+until the user requests that it be archived.  We also modified our portal
+server to support both RSPEC v1 and v2 specifications, extracting and 
+displaying the topology information embedded in these RSPECs.
+We also added the ability to view the
+topology/resources at various zoom levels, making it easier for users to get
+at the data they wish to observe.
+
+During this time, we also continued to support and operate the Juniper routers
+in the Internet 2 backbone, and have been using the routers in our testing
+and evaluation of the new Shadownet CM.
+
+Finally, we continue to have discussions with the PerfSONAR team to
+better understand how we can more tightly integrate the data collection from
+our logical routers with PerfSONAR.
+
+=== 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 (AT\&T)
+ * 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)
+ * Emmanouil Mavrogiorgis - Research Staff (AT\&T)
+
+=== C. Publications (individual and organizational) ===
+
+=== D. Outreach activities ===
+
+=== E. Collaborations ===
+
+Most of our collaborations have been with the Shadownet team.  In particular,
+it involves participants from Kentucky,
+AT\&T, and Internet2, but we have also had several conversations
+with our ProtoGENI and perfSONAR colleagues.
+
+=== F. Other Contributions ===
+