Context Navigation

← Previous Version
View Latest Version
Next Version →

Version 1 (modified by faber, 12 years ago) (diff)
--

Topology Description Language

We introduce topdl (topology description language) as the language for topology description. Our goal is to have a resource independent representation of communicating elements that can be used for experimentation. The basic model underlying topdl is a set of abstract elements that can communicate. To represent topologies at the level of detail that testbeds need to allocate resources and configure hardware, simple topdl descriptions are specialized by adding attributes.

Topdl is testbed independent and, in principle, different testbeds may treat the same topdl slightly differently. Different testbeds may interpret attributes differently. This document will explain how DETER tools interpret the topdl in an effort to encourage interoperability,

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.

Representation

Topdl is encoded in XML. Each substrate and element are encoded as XML elements with interfaces encoded in the elements. Attributes are attached to any of the XML elements. A full XSD encoding is available for qutomatically generating access code. This section will show some simple examples.

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>

Attachments (6)

two.png (3.6 KB) - added by faber 12 years ago. two node topology
two.xml (626 bytes) - added by faber 12 years ago. Simple topdl example file
example1.py (391 bytes) - added by faber 12 years ago. Python topdl example
example2.py (396 bytes) - added by faber 12 years ago. Python topdl example
example3.py (394 bytes) - added by faber 12 years ago. Python topdl editing example
two.tcl (164 bytes) - added by faber 12 years ago. ns2 example for fedd_ns2topdl.py

Download all attachments as: .zip

Download in other formats:

Plain Text