Changes between Initial Version and Version 1 of GeniDesktop_gec20_report


Ignore:
Timestamp:
07/18/14 14:17:37 (10 years ago)
Author:
griff@netlab.uky.edu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeniDesktop_gec20_report

    v1 v1  
     1[[PageOutline]]
     2
     3= GENI Desktop Project Status Report =
     4
     5Period: Post GEC 20 Report
     6
     7== I. Major accomplishments ==
     8
     9The following highlights our accomplishments during the last reporting period.
     10
     11=== A. Milestones achieved ===
     12
     13 * Develop regression testing suite to allow experimenters to verify essential network characteristics of provided topologies prior to experiementation.
     14
     15 * Demonstrate regression testing capabilities at GEC20.
     16
     17=== B. Deliverables made ===
     18
     19 * We developed code for doing regression test for GENI experiments.
     20
     21 * We enhanced the GENI Destkop to use the Common Federation Service API V2 as a first step towards implementing Speaks-for.
     22
     23 * We added support for Omni Stitcher to provide stitching support for slices that need layer-2 connections.
     24
     25 * We developed a slice membership function that allows slice membership changes after a slice/sliver has been created.
     26
     27 * We added a routing support function and a module for handling netflow data.
     28
     29== II. Description of work performed during last quarter ==
     30
     31The following provides a description of the progress made during the last reporting period.
     32
     33=== A. Activities and findings ===
     34
     35Our activities this last reporting period have been primarily focused on
     36developing code for regression testing of GENI experiments and making various
     37enhancements to the GENI Desktop's user interface and to the backend services
     38that support the GENI Desktop.
     39
     40The goal of regression test is to make sure that the nodes and links in the
     41topology are set up and working correctly.  As the size of GENI slices (i.e.,
     42topologies) grows, the statistical probability of some resource
     43not booting correctly, having a network interface that is not operating or
     44configured correctly, or any other type of initialization error increases
     45quickly.  As anyone who has tried to create a relatively large slice knows,
     46the chance of some part of the slice not coming up correctly is extremely likely.
     47The control framework is often able to detect major failures, but it is
     48not good at detecting failures that are not obvious.  For example, two nodes
     49may have come up and been configured correctly, but the VLAN or GRE tunnel
     50connecting the interfaces on the nodes has a problem of some sort.
     51Discovering such errors requires using the link between the two nodes to see
     52that packets are not getting through, are being delayed, lost, etc.
     53
     54To address this issue, we designed an algorithm that can efficiently
     55distribute the post-boot regression testing tasks needed to verify correct
     56slice operation.  The algorithm divides up the tasks such that each node in
     57the slice is responsible for testing its own configuration and its
     58connectivity to its neighbors.  One version of the algorithm is centrally
     59controlled by the GN which distributes the tasks and collects the responses.
     60A second version of the algorithm arranges the nodes into a distribution tree
     61structure so that the work of distributing the tasks and collecting the
     62results is distributed among all nodes.  As a result, the algorithm is
     63scalable to very large experiments.  Our primary focus for regression test at
     64the moment is link connectivity.  We are in the process of incorporating the
     65regression testing module into the GENI Desktop.
     66
     67We also added slice membership functionality to the desktop.  Previously this
     68type of functionality was only available at the GENI Portal.  The new
     69functionality allows users to add new members to a slice even after the slivers
     70has been created. In general, a member of a slice can be removed from the
     71slice, or changed to a different role (lead, admin, member, auditor). A
     72non-member can be added to a slice as either a lead, an admin, a member, or
     73an auditor. This provides the flexibility for the slice owner to modify the
     74access rights of other members from the same project.
     75
     76We also enhanced the GENI Desktop in several other less visible ways (i.e.,
     77changes to the backend services). First, we used the Common Federation
     78Service 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
     79stitched together at layer 2 if stitching functionality exists between them.
     80If the RSpec provided by the user contains nodes from mulitple aggregates and
     81specifies using layer-2 connections between any two nodes, the GENI Desktop
     82will determine if sticher is needed and then use it providing the user with a web log of the operation.
     83
     84Secondly, we added a new module to the GENI Desktop that allows users to
     85control the IPv4 paths (routes) between nodes at runtime.  A user can use the
     86GENI Desktop topology graph to interactively select the routers that should
     87form a path from a source to a destination.  The new module will then modify
     88the routing tables at each intermediate node so that the traffic from the
     89source to the destination will take the selected path, instead of the default
     90path.  This is done by adding host-specific routes so all traffic between
     91those two nodes will flow along the path.
     92
     93Third, we added a module to the GENI Desktop to handle netflow data. The user
     94can choose what netflow data will be collected at each experimental node, and
     95what part of the collected data will be displayed on the user interface.
     96
     97Finally, we demonstrated these new features of the GENI Desktop at the GEC 20
     98conference.
     99
     100=== B. Project participants ===
     101
     102The following individuals are involved with the project in one way or another:
     103 * Jim Griffioen - Project PI (Kentucky)
     104 * Zongming Fei - Project Co-PI (Kentucky)
     105 * Hussamuddin Nasir - Technician/Programmer (Kentucky)
     106 * Charles Carpenter - Technician/Programmer (Kentucky)
     107 * Xiongqi Wu - Ph.D. Student
     108 * Jeremy Reed - Ph.D. Student
     109
     110=== C. Publications (individual and organizational) ===
     111
     112=== D. Outreach activities ===
     113
     114 * We presented during the demo session at GEC 20 showing the newly implemented functions of the GENI Desktop.
     115
     116=== E. Collaborations ===
     117
     118 * Most of our collaborations have been between the GPO Portal team, the Indiana GEMINI team and the Utah team.
     119
     120=== F. Other Contributions ===