Changes between Version 9 and Version 10 of LayoutAspect

Timestamp:

Oct 15, 2013 2:41:09 PM (11 years ago)

Author:

faber

Comment:

--

LayoutAspect

@@ -3 +3 @@
 = Describing And Manipulating Experiment Topologies in DETER =
 
-This page describes the model, specification and implementation of DETER's topology description.  A topology is the layout of an experment's physcial or logical environment including the connections that make up of its control and data networks.  It is a description of the elements that a researcher can manipulate and a characterization of how those elements communicate.
+This page describes the model, specification and implementation of DETER's topology manipulation system.  A topology is the layout of an experment's physcial or logical environment including the connections that make up of its control and data networks.  It is a description of the elements that a researcher can manipulate and a characterization of how those elements communicate.
 
-Different users of the topology view it different ways. A researcher studying the propagation of a security compromise may make use of a recursive tool to create a topology.  Because it was generated by a recursive tool, a natural representation is in recursive chunks, and these may result in a very compact specification.
+Different users of a topology view it different ways. A researcher studying the propagation of a security compromise may make use of a recursive tool to create a topology.  Because the topology was generated by a recursive tool, a natural representation is in recursive chunks, which may result in a very compact specification.
 
-The researcher has a different breakdown of the experiment. In their mind the topology consists of a routing backbone, some enterprise networks, and a set of enterprise networks containing compromised computers.  This breakdown of the topology can also be characterized in terms of chunks that are defined, not by the workings of the construction algorithm, but by the semantics of the researcher's experiment.
+The researcher has a different breakdown of the experiment than the generation tool. In their mind the topology may consist of a routing backbone, some enterprise networks, and a set of enterprise networks containing compromised computers.  This breakdown of the topology can also be characterized in terms of chunks that are defined, not by the workings of the construction algorithm, but by the semantics of the researcher's experiment.
 
 Finally, when the testbed realizes the topology, it will assign physical resources to each element and substrate.  If the topology is heavily virtualized it may be helpful for the researcher (or testbed staff) to see the topology broken into chunks that map to physical machines in the testbed.
@@ -13 +13 @@
 We call those different descriptions of the same topology ''views'' and the testbed supports creating a topology from one view, accepting additional views from users, and synthesizing new views internally.  When viewing ore manipulating a topology, a user of the testbed can query the views available and select the one that suits their needs.
 
-Inherent in a view is the definition of regions of semantic importance that can be shown, acted on, or extracted and reused by a researcher.  These regions allow the testbed to present topological information to the user only when required, enabling users to deal with the congnitive and bandwidth overhead of manipulating large topologies.
+Inherent in a view is the definition of regions of semantic importance that can be shown, acted on, or extracted and reused by a researcher.  These regions allow the testbed to present topological information to the user only when required, enabling users to deal with the congnitive overhead and information transfer costs of manipulating large topologies.
 
-We describe a model that suports these, an API that describes how to use the model and an initial implementation in the Descartes interface.
+We describe a model that suports such multi-view topologies, an API that describes how to use the model and an initial implementation in the Descartes interface.
 
 == Model ==
 
-We describe the model in a bottom up format, first describing the atoms from which a view are constructed and then how to combine them into a full view.  Once we have defined the view model, we discuss specifying and manipulating multiple views through the testbed interface.
+We describe the model in a bottom up fashion, first describing the atoms from which a view are constructed and then how to combine them into a full view.  Once we have defined the view model, we discuss specifying and manipulating multiple views through the testbed interface.
 
-The view description is not tied to the Descartes inteface, and can be used by other tools for describing and manipulating topologies.  The interfaces for creating a topology, requesting different views of it, and assigning new views are specific to Descartes.
+The view model is not tied to the Descartes inteface, and can be used by other tools for describing and manipulating topologies.  The interfaces for creating a topology, requesting different views of it, and assigning new views are specific to Descartes.