Federation in Support of Multi-Party Experiments

Multi-party experiments are a research activity undertaken by multiple experimenters or groups of experimenters that requires differing views of the environment. For example, a multi-party security experiment may pit an attack designer against a defense designer, each with limited visibility and control of the system. Such environments may also support collaboration.

Conceptually, multiple users come to DETER with experiment fragments and constraints on how those fragments are combined and DETER creates the composite environment that meets those constraints.

DETER's support for this is evolving. Our initial implementation uses the simple composition system to combine partial topologies automatically, subject to constraints, and the federation to construct the composite topologies in DETER as federated experiments with individual service configurations.

This page documents the proof of concept implementation. More work is ongoing in making this system more broadly usable and expressive.

Combining partial topologies

One aspect of combining multiple environments is building a single overall topology, even if no individual player will be able to see all of it. We use a simple label-matching constraint resolver to combine topology fragments. Each node in a fragment may be annotated with constraints that describe how it can be attached to nodes in other fragments. Each node has one or more attachment points, each of which as one or more labels attached to it, called the attachment point's type. Additionally each attachment point may only be attached to points that have labels specified in its "Link to" list.

In the example below, the two left most nodes have a single attachment point of type "Single". They can only be attached to points of type "Node". The next node has connections of type "Node" that can connect to either "Node" or "Single" connections. They combine to form a 3-node fragment with one attachment point type "Node" that can connect to either "Node" or "Single" connections.

These fragments can either be described in the extended ns-2 language or in simple xml containing a ​topdl description. The three-connection node is encoded in ns-2 as:

# simple DETER topology
# COMPOSITION: bot0:optional:Node:Single,Node
# COMPOSITION: bot0:optional:Node:Single,Node
# COMPOSITION: bot0:optional:Node:Single,Node

set ns [new Simulator]
source tb_compat.tcl


set bot0 [$ns node]
tb-set-node-testbed $bot0 "deter"

$ns rtproto Static
$ns run 

The comments containing the COMPOSITION keyword contain the constraints. The first colon-separated field gives the node name to which the constraint applies, the second whether the field is optional or required, the third the type of connector, and the last a comma-separated list of acceptable types to connect. Optional constraints need not be satisfied, though our satisfier tries to satsify as many as possible.

The same component in XML is:

<component>
 <constraints>
  <constraint>
   <name>bot0</name>
   <required>False</required>
   <provides>Node</provides>
   <accepts>Single</accepts>
   <accepts>Node</accepts>
  </constraint>
  <constraint>
   <name>bot0</name>
   <required>False</required>
   <provides>Node</provides>
   <accepts>Single</accepts>
   <accepts>Node</accepts>
  </constraint>
  <constraint>
   <name>bot0</name>
   <required>False</required>
   <provides>Node</provides>
   <accepts>Single</accepts>
   <accepts>Node</accepts>
  </constraint>
 </constraints>
 <experiment>
  <version>1.0</version>
  <elements>
   <computer>
    <name>bot0</name>
    <attribute>
     <attribute>type</attribute>
     <value>pc</value>
    </attribute>
    <attribute>
     <attribute>testbed</attribute>
     <value>deter</value>
    </attribute>
    <attribute>
     <attribute>failureaction</attribute>
     <value>fatal</value>
    </attribute>
   </computer>
  </elements>
 </experiment>
</component>