wiki:GeniDesktop_gec20_report

Version 1 (modified by griff@netlab.uky.edu, 5 years ago) (diff)

--

GENI Desktop Project Status Report

Period: Post GEC 20 Report

I. Major accomplishments

The following highlights our accomplishments during the last reporting period.

A. Milestones achieved

  • Develop regression testing suite to allow experimenters to verify essential network characteristics of provided topologies prior to experiementation.
  • Demonstrate regression testing capabilities at GEC20.

B. Deliverables made

  • We developed code for doing regression test for GENI experiments.
  • We enhanced the GENI Destkop to use the Common Federation Service API V2 as a first step towards implementing Speaks-for.
  • We added support for Omni Stitcher to provide stitching support for slices that need layer-2 connections.
  • We developed a slice membership function that allows slice membership changes after a slice/sliver has been created.
  • We added a routing support function and a module for handling netflow data.

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 activities this last reporting period have been primarily focused on developing code for regression testing of GENI experiments and making various enhancements to the GENI Desktop's user interface and to the backend services that support the GENI Desktop.

The goal of regression test is to make sure that the nodes and links in the topology are set up and working correctly. As the size of GENI slices (i.e., topologies) grows, the statistical probability of some resource not booting correctly, having a network interface that is not operating or configured correctly, or any other type of initialization error increases quickly. As anyone who has tried to create a relatively large slice knows, the chance of some part of the slice not coming up correctly is extremely likely. The control framework is often able to detect major failures, but it is not good at detecting failures that are not obvious. For example, two nodes may have come up and been configured correctly, but the VLAN or GRE tunnel connecting the interfaces on the nodes has a problem of some sort. Discovering such errors requires using the link between the two nodes to see that packets are not getting through, are being delayed, lost, etc.

To address this issue, we designed an algorithm that can efficiently distribute the post-boot regression testing tasks needed to verify correct slice operation. The algorithm divides up the tasks such that each node in the slice is responsible for testing its own configuration and its connectivity to its neighbors. One version of the algorithm is centrally controlled by the GN which distributes the tasks and collects the responses. A second version of the algorithm arranges the nodes into a distribution tree structure so that the work of distributing the tasks and collecting the results is distributed among all nodes. As a result, the algorithm is scalable to very large experiments. Our primary focus for regression test at the moment is link connectivity. We are in the process of incorporating the regression testing module into the GENI Desktop.

We also added slice membership functionality to the desktop. Previously this type of functionality was only available at the GENI Portal. The new functionality allows users to add new members to a slice even after the slivers has been created. In general, a member of a slice can be removed from the slice, or changed to a different role (lead, admin, member, auditor). A non-member can be added to a slice as either a lead, an admin, a member, or an auditor. This provides the flexibility for the slice owner to modify the access rights of other members from the same project.

We also enhanced the GENI Desktop in several other less visible ways (i.e., changes to the backend services). First, we used the Common Federation Service API V2 for backend functionality that retrieves user info from the Slice Authorities which was previously provided to the Genidesktop directly by the GeniPortal. We also moved to using omni2.6 in the backend to provide stitching support, so that nodes can now be stitched together at layer 2 if stitching functionality exists between them. If the RSpec provided by the user contains nodes from mulitple aggregates and specifies using layer-2 connections between any two nodes, the GENI Desktop will determine if sticher is needed and then use it providing the user with a web log of the operation.

Secondly, we added a new module to the GENI Desktop that allows users to control the IPv4 paths (routes) between nodes at runtime. A user can use the GENI Desktop topology graph to interactively select the routers that should form a path from a source to a destination. The new module will then modify the routing tables at each intermediate node so that the traffic from the source to the destination will take the selected path, instead of the default path. This is done by adding host-specific routes so all traffic between those two nodes will flow along the path.

Third, we added a module to the GENI Desktop to handle netflow data. The user can choose what netflow data will be collected at each experimental node, and what part of the collected data will be displayed on the user interface.

Finally, we demonstrated these new features of the GENI Desktop at the GEC 20 conference.

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)
  • Hussamuddin Nasir - Technician/Programmer (Kentucky)
  • Charles Carpenter - Technician/Programmer (Kentucky)
  • Xiongqi Wu - Ph.D. Student
  • Jeremy Reed - Ph.D. Student

C. Publications (individual and organizational)

D. Outreach activities

  • We presented during the demo session at GEC 20 showing the newly implemented functions of the GENI Desktop.

E. Collaborations

  • Most of our collaborations have been between the GPO Portal team, the Indiana GEMINI team and the Utah team.

F. Other Contributions