The DFA Plugin Architecture

Access controllers are customized to the underlying testbed technology and testbed policies of a resource provider. In order to connect custom access controllers we define an interface for creating and manipulating the testbed topologies that experiment controllers use to talk to access controllers. Access controllers can be integreted into the fedd codebase or be stand-alone controllers that are accessible through these interfaces.

Key to these interfaces is a topology description language, topdl, that defines experiment topologies and sub-topologies at a level of abstraction that can be specialized when necessary. We discuss topdl below after defining the basic interfaces and terminology.

If you are interested in developing a plug-in, you should proceed to the detailed interface description when you have finished this one. There is another link to that page at the bottom of this one.

Operations

The following operations are valid on an access controller:

Grant Access

Configure the local testbed to allow the researcher to allocate resources. The request includes the researcher's credentials and optionally an estimate of the resources required and allocation timeframe. This allocation is bound to a fedid. This operation allows a testbed to configure itself - for example an emulab-style testbed may add projects or user accounts at this point.

Start Segment

Make of resources to the experiment and bind it to the allocation created above. At this point the testbed resource allocation system is run on the specific resource topology requested. This is an initial allocation, so any testbed-specific operations used in creating a new allocation are carried out.

Terminate Segment

Remove the resources created above. Notice that the fedid-bound allocation still exists, so that new resources can be allocated to it.

Remove Access

Release the fedid-bound allocation. At this point a testbed may reclaim any local resources bound to that allocation outside the experiment resources.

These are encoded as the RequestAccess, ReleaseAccess, StartSegment, and TerminateSegment operations in the web service interface.

In the future we will be expanding these operations to include support for more informantion and manipulation of federated experiments, inclucing manipulating nodes in an experiment and changing experiment topology.

Topology Description Language

The two keys to an effective interface for local resource allocation guided by the global event controller are a representation of credentials and authorization and a representation of the resources being requested. This section deals with the resource description for sub-experiments at differing levels of abstraction depending on the testbed.

We introduce topdl (topology description language) as the language for topology description. An XSD representation and sample manipulation library are available from the source tree. The goal of the language is to represent experimental topologies at sufficient detail so that local testbeds can allocate resource configured appropriately for the experiment.

There are two primitives in topdl:

Elements

Active resources in the experiment: computers, routers, devices that are programmable. These are subclassed for common kinds of elements

Substrate

A communications medium to which elements have access. This may be a wired LAN, a shared communication frequency, or may represent the fact that the elements share a line of sight.

The point of contact between these primitives is:

Interface

An indication that a particular element can communicate on one or more substrates. An interface appears on exactly one element.

These are deliberately unconstrained, but are an attempt to capture the idea that most network experiments are about things that can talk to other things in constrained ways.

Each subclass and substrate has parameters which set the specifics of that object. For example, the computer subclass of elements can be parameterized by the operating system, the CPU information, the required software, and the storage (memory, disk, etc) that are required. Additional attribute/value pairs (strings) can be attached to the computer (and to some of the parameters) to specialize it for specific access controllers or other applications.

Substrates and interfaces can also have attributes attached, but are characterized by the communication capacity and latency of the substrate, though neither needs to be specified if unimportant.

By specializing these primitives, topdl can represent many network topologies. A traditional enterprise configuration can be represented as computer elements for each desktop connected by substrates that represent the LANs that are also interfaces to routers and firewalls that model the system. A system of nodes sharing the same wireless infrastructure share interfaces on the same wireless substrate. Machines that can talk on more than one substrate using the same interface - for example a multi-frequency radio - are specified with one interface on several substrates, one for each frequency of interest.

While limits will certainly be found, this simple elements in substrates model covers a broad range of useful topologies.

By binding specific attributes to the elements of an experiment, the description can be customized to constrain the details of interest to a researcher and that are useful to a particular testbed technology. Researchers studying worm propagation may be more interested in the interconnection of computers and the installed software than in the particular CPU models on the computers. Other researchers may be very concerned with the particular hardware or transmission technology of, say, the wireless interfaces. Attaching attributes provides a mechanism to communicate these preferences.

Of course, not every federant/access controller will understand each attribute, which is why some attributes and requirements are codified now and all access controllers are expected to respect them. The semantics of unformalized attributes can represent agreements between researchers and resource providers, and widely supported attributes will become formalized parameters. If the changes in element behavior are sufficient, a subclass may be created.

Current Element Classes and Attributes

These are the current supported standard classes and some attributes that are in use by the current fedd code.

Substrate

Substrates are parameterized by:

Name

A unique name to tie interfaces to this substrate.

Capacity

The rate of information exchange on this substrate. May be given as an average or peak rate.

Latency

The time required for information to cross this substrate. May be an average or a peak.

An interface may also have those parameters, in which case the element to which the interface is attached is limited by the lower of the interface or substrate values. Corner cases, such as a maximum less than an average are dealt with as errors by the system taking the topology as input.

Elements

There are several subclasses in use. The generic element class has no specific parameters, only unstandardized attributes.

Current subclasses include:

Computer

In addition to unstandardized attributes, computers are parameterized by:

Name

An identifier for the computer, primarilty useful to researchers directly.

CPU

They type and number of CPUs required

Operating System

Including version, distribution, and patchlevel

Storage

Amount of persistent and transient storage - usually disk and memory, but new technologues are possible.

Software

The software to install and the location in the file system. A URI may be given for the software distribution.

Interfaces

Parameterized as above

Segment

A sgement is an allocation (or future allocation) of resources to a federated experiment. They are useful placeholders in establishing connectivity across a federant that acts as a transit network provider between federants. The optional parameters include:

Name

Name of the segment. Primarily useful to reserachers or debuggers.

Type

Access controller type, e.g., emulab.

URI

The URI at which the access controller can be found.

Interfaces

The parameterized as above

Attribute Conventions

Though we expect attribute conventions to evolve, currently the following entension attributes are understood. Several are being used to bridge from the existing experiment description language to current topdl, and are somewhat emulab-specific.

failureaction

What the underlying testbed should do if this node cannot be reserved or configured. Choices are fatal or nonfatal.

osid

The local emulab operating system image. This will become less common as more plugins are capable of mapping from operating system parameters into local image name, but can be used as a low-level escape.

testbed

The experiment controller's name for the testbed this node will be placed on. This is in place to allow native topdl descriptions to be accepted by experiment controllers - it's not needed by access controllers. As the full experiment description language evolves, this may move into som part of that language or become a standard topdl attribute.

type

The local emulab machine type. This will become less common as more plugins are capable of mapping from CPU/storage parameters into local machine type, but can be used as a low-level escape.

The following attributes appear in topology descriptions for use by local emulabs in configuration:

active

Attached to a portal computer. If true, this portal initiates connections to the peer.

dragon_vlan

If assigned, the VLAN tag on which this node will communicate. The name will change.

domain

Attached to a portal computer. This is the DNS domain of the local emulab resources.

ip4_address

The IP version 4 address of the interface that the attribute is attached to as a dotted decimal.

masterdomain

Attached to a portal computer. The DNS domain of the emulab exporting its environment. Used to connect services and forward traffic.

masterexperiment

Attached to a portal computer. The emulab project/experiment name of the environment being exported from the master testbed. Used to connect services.

masteruser

Attached to a portal computer. The emulab user that alloacted the exported environment on the master. User to connect to services.

peer

Attached to a portal computer. DNS name of the portal node used to bridge services and traffic.

peer_segment

Attached to a portal computer. Fedid of the allocation in which the peer portal lives.

portal

True if this is a portal computer added by the experiment controller

portal_type

Attached to a portal computer. Specifies whether this portal exports services, forwards traffic, or both.

smbshare

Attached to a portal computer. The SMB/CIFS share used to export local file systems (if any)

startup

The startup command to federate the computer.

Example

As an example, here is the experiment description from the architecture discussion, rendered in topdl.

<experiment>
 <substrates>
  <name>link0</name>
  <capacity>
   <rate>100000</rate>
   <kind>max</kind>
  </capacity>
 </substrates>
 <substrates>
  <name>lan0</name>
  <capacity>
   <rate>100000</rate>
   <kind>max</kind>
  </capacity>
 </substrates>
 <substrates>
  <name>link1</name>
  <capacity>
   <rate>100000</rate>
   <kind>max</kind>
  </capacity>
 </substrates>
 <elements>
  <computer>
   <name>d</name>
   <attribute>
    <attribute>type</attribute>
    <value>bvx2200</value>
   </attribute>
   <os>
    <attribute>
     <attribute>osid</attribute>
     <value>FC6-SMB</value>
    </attribute>
   </os>
   <interface>
    <substrate>lan0</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <attribute>
    <attribute>testbed</attribute>
    <value>ucb</value>
   </attribute>
   <attribute>
    <attribute>failureaction</attribute>
    <value>fatal</value>
   </attribute>
  </computer>
 </elements>
 <elements>
  <computer>
   <name>e</name>
   <attribute>
    <attribute>type</attribute>
    <value>bvx2200</value>
   </attribute>
   <os>
    <attribute>
     <attribute>osid</attribute>
     <value>FC6-SMB</value>
    </attribute>
   </os>
   <interface>
    <substrate>lan0</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <attribute>
    <attribute>testbed</attribute>
    <value>ucb</value>
   </attribute>
   <attribute>
    <attribute>failureaction</attribute>
    <value>fatal</value>
   </attribute>
  </computer>
 </elements>
 <elements>
  <computer>
   <name>a</name>
   <attribute>
    <attribute>type</attribute>
    <value>pc</value>
   </attribute>
   <os>
    <attribute>
     <attribute>osid</attribute>
     <value>FC6-STD</value>
    </attribute>
   </os>
   <interface>
    <substrate>link0</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <attribute>
    <attribute>testbed</attribute>
    <value>deter</value>
   </attribute>
   <attribute>
    <attribute>failureaction</attribute>
    <value>fatal</value>
   </attribute>
  </computer>
 </elements>
 <elements>
  <computer>
   <name>b</name>
   <attribute>
    <attribute>type</attribute>
    <value>pc</value>
   </attribute>
   <os>
    <attribute>
     <attribute>osid</attribute>
     <value>FC6-STD</value>
    </attribute>
   </os>
   <interface>
    <substrate>link0</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <interface>
    <substrate>link1</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <attribute>
    <attribute>testbed</attribute>
    <value>deter</value>
   </attribute>
   <attribute>
    <attribute>failureaction</attribute>
    <value>fatal</value>
   </attribute>
  </computer>
 </elements>
 <elements>
  <computer>
   <name>c</name>
   <attribute>
    <attribute>type</attribute>
    <value>bvx2200</value>
   </attribute>
   <os>
    <attribute>
     <attribute>osid</attribute>
     <value>FC6-SMB</value>
    </attribute>
   </os>
   <interface>
    <substrate>lan0</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <interface>
    <substrate>link1</substrate>
    <capacity>
     <rate>100000</rate>
     <kind>max</kind>
    </capacity>
   </interface>
   <attribute>
    <attribute>testbed</attribute>
    <value>ucb</value>
   </attribute>
   <attribute>
    <attribute>failureaction</attribute>
    <value>fatal</value>
   </attribute>
  </computer>
 </elements>
</experiment>

People with an interest in plug-in development will want to continue to the detailed interface description