wiki:GENIOESSTopologiesTestPlan

Version 2 (modified by lnevers@bbn.com, 6 years ago) (diff)

--

GENI OESS Topologies

This test plan describe how the Open Exchange Software Suite (OESS) AM will be validated for functions that are relevant to GENI. OESS is a set of software that can be used to configure and control dynamic layer 2 virtual circuits, such as those provided for Advanced Layer 2 Services (AL2S). The OESS software supports circuit provisioning, automatic circuit fail-over, per-interface permissions, and automatic per-VLAN statistics. This test plan will use OESS to verify topologies that include multiple GENI sites. The test plan will also check that GENI experimenters can use different GENI Aggregate Managers to select differing valid VLAN paths between GENI endpoints. The tests will also check the ability of AL2S monitoring to collect statistics on GENI slices and traffic that traverse VLANs that the OESS software creates. These are the overall goals of this plan:

  • Verify that the aggregates present an accurate picture of resources available.
  • Verify that experimenters can get the resources they request.
  • Verify that operators can tell what resources are in use, and determine who is using the resources.
  • Validate representative network topologies and collect statistics and monitoring data for those topologies

Assumptions:

  1. Testing may start with statically configured OESS circuits if necessary, and switch to Dynamic OESS circuit configuration when available.

  1. There is no OpenFlow support tested in any test case described in this plan.
  1. Cross connects between AL2S and ION networks (which were provisioned 9 months ago for a demonstration) will be available for continuing use.
  1. GPO can access information from AL2S test points.

OESS-T1 Functional Tests

Documentation is not currently available, thus making this test plan incomplete. Updates will be made to all sections as information becomes available. If documentation is not available, test findings will be used to defined functions found.

  1. Get access to OESS software pointed to AL2S (I2 has to enable this when they are done their own testing) and documentation
  2. Get access to I2 development test results.
  3. Create VLANs along a new path. Verify connectivity with available Internet2-managed AL2S test points.
  4. Delete VLAN and verify release
  5. Modify existing path

Topology Scenarios

OESS-T2 Two Site Cross-connect tests

Two endpoints will be connected with the following cross-connects, listed by priority:

  1. ION to AL2S experiment: Experiment will connect GPO IG ION to MAX IG AL2S.
  2. Meso-scale to AL2S experiment: Experiment will connect GPO IG ION to Meso-scale VLAN to MAX AL2S. Or if available, experiment may use NYU IG Meso-scale to MAX IG AL2S.
  3. AL2S to AL2s experiment: Experiment will connect MAX IG AL2S to an AL2S Test Point. (see note1)

note1: AL2S test-points are available and will be used throughout testing to help establish network connections defined in this plan.

OESS-T3 Two Site Multiple VLANs Cross-connect tests

The tests defined above (OESS-T2) will be re-run with multiple simultaneously-active VLANs defined between the same two endpoints. Details:

  1. ION-to-AL2S: Connect two sites with multiple VLANS, each of which uses an ION to AL2s cross-connect path (GPO IG ION <-path 1-> MAX IG AL2S + GPO IG ION <-path 2-> MAX IG AL2S). This test results in multiple VLANs being active on the link to the endpoint node simultaneously.
  2. Meso-scale-to-AL2S: Connect one site via meso-scale and one site via AL2S, with multiple VLANs between them. (NYU IG Meso-scale <-link1-> MAX IG AL2S + NYU IG Meso-scale <-link1-> MAX IG AL2S) (see note2)
  3. AL2S-to-AL2s: Conect two sites with multiple AL2S VLANs between them. (MAX IG AL2S to AL2S Test Point1 + MAX IG AL2S to AL2S Test Point2)
  4. Combination: Connect two sites, each of which use different paths, to a third site. One path uses ION to AL2S, second path uses meso-scale to AL2S (GPO IG ION to MAX IG AL2S + NYU IG Meso-scale to MAX IG AL2S)
  5. Remove/add VLANs. For any of the 4 scenarios above, verify that it is possible to delete or add VLANs between the same sites without affecting the other active VLANs. This test assumes that total traffic on the VLANs is well below the link limits.

note2: If NYU IG meso-scale is not available, experiment will connect GPO ION to meso-scale in its place

OESS-T4 Multiple sites scenarios

Starting with the GPO IG and MAX IG sites, make connections to 1 or 2 more sites as they become available. Currently we expect that University of Wisconsin and University of Missouri are the most likely upcoming candidates that will support OESS. Other less likely candidates are University of Idaho, Clemson University, and University of Indiana.

If 3 sites are available, the following topologies will be tested:

  1. Three nodes linear (Site1 <-link-> Site2 <-link-> Site3)
  2. Three nodes loop (Site1 <-link-> Site2 <-link-> Site3<->Site1)

If 4 sites are available, the following topologies will be tested.

  1. Four nodes linear (Site1 <-link-> Site2 <-link-> Site3<->Site4)
  2. Four nodes loop (Site1 <-link-> Site2 <-link-> Site3<->Site4<->GPO IG)
  3. Four nodes star (Site1 is center node)

For any of the available topologies, verify that it is possible to add and delete VLANs without affecting the other existing VLANs. For any of the available topologies, verify that it is possible to add or delete a site from a group of sites operating with existing VLANs between them.

OESS-T5 Traffic Handling and Statistics Gathering

For each test scenario outlined in this plan, both TCP and UDP traffic will be exchanged between the endpoint sites to verify that connections work as expected. Also, statistics will be gathered to show connection usage.

OESS-T6 Resource Monitoring

Although we don't have monitoring documentation for OESS to verify intended functions, we expect that experimenters and operators can see information about circuits, VLANs, aggregates and components that make the topologies available.

Current goal, which may change, is to verify the ability to access monitoring data that allows tracking the following over time:

  • existing slices/experiments
  • mapping slices/experiments to resources/slivers
  • mapping slices to sliver to user
  • map circuit ID to sliver or slice.
  • map VLAN ID on a given port to a sliver or slice.
  • Cross-connect traffic statistics

Note: If stitching is possible, it is expected that the available connections are documented in a VLAN delegation page, as is currently done for GENI stitching VLANs in other networks.

OESS-T7 Administrative/Operator functions

These functions are important for operators in GENI, so that they can track traffic to and from their site through GENI aggregates.

Operator access to the following OESS information will be verified (note the operator is not the same as the experimenter):

  • Allocated VLANs for use by Aggregate responsible for cross-connect path.
  • Verify Aggregate Advertisement reflects the VLAN allocation
  • Add/Modify/Delete the VLANs available for the aggregate, verify Advertisement reflects change for each add/modify/delete operation.
  • Modify the endpoints for a VLAN, verify Advertisement reflects change.
  • Bandwidth allocation for cross-connect (if available)
  • Verify Aggregate Advertisement reflects configured bandwidth allocation defined by operator.
  • Traffic statistics for all GENI traffic to/from an operators site on OESS
  • Operator ability to delete existing VLANs that terminate at their site (the operator is not the experimenter who set up the connections).