Changes between Version 26 and Version 27 of GENIFlowSpaceFirewallTests

Timestamp:

05/08/14 17:48:05 (10 years ago)

Author:

hdempsey@bbn.com

Comment:

minor wording changes

GENIFlowSpaceFirewallTests

@@ -12 +12 @@
   * Confirm FSF ability to support a simple GENI learning switch controller for various topologies.
   * Confirm FSF ability to support multiple concurrent add/delete learning switch controller requests. 
-  * Verify rate limiting
-  * Confirm ability to query statistics for switch, links, firewall rules with !FloodLight rest API.
+  * Verify rate limiting,if any, on the control plane.  (No rate limiting enforced on the AL2S data plane with FSFW)
+  * Confirm ability to collect AL2S and FSFW usage statistics relevant to these test scenarios via SNAPP and GENI local datastore monitoring interfaces. Example statistics include total flows, flowmods/sec, VLANs throughput on switches and links, active GENI slices/slivers.  See the GENI monitoring use cases for more detail on statistics not specifically realted to FSFW.
   * Run through Internet2 procedures for qualifying and running an experimenter controller in AL2S and provide feedback to I2 to streamline the procedures as much as possible, and ensure experimenters can get complete and accurate documentation to help guide them through procedures.
 
@@ -25 +25 @@
     * End-point traffic types generated include UDP, TCP, and ICMP.
     * Layer 2 hardware matching is validated.  There is no Layer 3 matching at this time.  (Layer 3 matching tests will be done when AL2S makes that capability available.)
-    * Tests are described in this plan with the assumption that GENI network stitching is available from OESS. 
-    * OESS may not be available, so sliver creation may be done in 2 steps:
-       - AL2S circuits will be set up to connect the edge ports.
-       - Stitched slivers with fixed AL2S endpoints are created for IG sites. 
+    * Tests are described in this plan with the assumption that GENI network stitching is available from OESS AM. 
+    * OESS AM may not be available, so sliver creation may be done in 2 steps:
+       - AL2S circuits will be set up to connect the edge ports.  (This may require manual setup by I2, because of the VLAN range restrictions for FSFW)
+       - Stitched slivers with fixed AL2S endpoints are created for IG sites.
+    * Each test lists rack endpoints we intend to use for those tests.  Other racks may be substituted if necessary due to outages or scheduled events such as tutorials, although all racks were unscheduled as of May 2.
 
 == FSF-T1 Two Sites Functional tests ==
 
-Initial testing will take place with two sites that are already connected to AL2S.  Multiple slivers will be created by multiple experimenters. 
+Initial testing will take place with two sites that are already connected to AL2S.  Multiple slivers will be created by multiple "experimenters."  (All experimenters will actually be GPO staff.) 
 
 [[Image(fsfw-test-topology-step1.jpg)]]
@@ -39 +40 @@
 Functional testing is executed within these simple node experiments:
 
- 1. Create a slice which results in VLANs allocation between AL2S InstaGENI end-points and exchange traffic. Verify AL2S router proxy statistics. 
- 2. Create slices to use configured number of VLANs, verify configuration is enforced and reflected in AL2S router proxy statistics.
+ 1. Create a slice which establishes VLANs between AL2S InstaGENI end-points and exchange traffic between the rack endpoints. Verify AL2S router proxy statistics. 
+ 2. Create slices and generate traffic to use all the VLANs specified for the endpoints (see configuration information listed in Network Details).  Verify VLANs are successfully created and traffic is flowing as expected in AL2S router proxy statistics. Verify traffic in GENI local data store measurements to the extent possible.
  3. Delete slices and and verify release of VLANs via AL2S router proxy. 
  4. Submit multiple concurrent requests to add and to delete flow spaces.
- 5. Configure various rate limits and verify enforcement.  
- 6. Query FSF status and rules via !FloodLight rest API.
+ 5. Test limits configured in FSFW for control plane rate limits, and  verify enforcement.  (This step likely requires cooperation from I2, since GPO may not have the ability to directly affect controller to attempt to exceed control plane rate limits._
+ 6. Query FSF status and rules via SNAPP.
  7. Generate traffic outside of pre-defined flowspace and verify that it is handled properly.
- 8. Create slice requesting specific VLAN outside of FSF range, verify rejection.
- 9. Request network capacity beyond configured FSF capacity, verify enforcement.
+ 8. Create slice requesting specific VLAN outside of FSFW range, verify rejection.
+ 9. Request network capacity beyond configured FSF capacity, verify that request fails.
 
 Network Connection details for this 2 node topology:
@@ -68 +69 @@
 
 __ION to AL2S cross-connects__ [[BR]]
-The following cross-connects will be verified in the !OpenFlow topologies shown above are:
+The following cross-connects will be verified in the !OpenFlow topologies shown above:
  1. sdn-sw.losa e1/1 <-> rtr.losa:port=et-10/0/0
  2. sdn-sw.atla e15/1 <-> rtr.atla:port=xe-0/3/0