Changes between Version 9 and Version 10 of LayoutAspect


Ignore:
Timestamp:
Oct 15, 2013 2:41:09 PM (10 years ago)
Author:
faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • LayoutAspect

    v9 v10  
    33= Describing And Manipulating Experiment Topologies in DETER =
    44
    5 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.
     5This 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.
    66
    7 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.
     7Different 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.
    88
    9 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.
     9The 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.
    1010
    1111Finally, 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.
     
    1313We 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.
    1414
    15 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.
     15Inherent 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.
    1616
    17 We describe a model that suports these, an API that describes how to use the model and an initial implementation in the Descartes interface.
     17We 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.
    1818
    1919== Model ==
    2020
    21 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.
     21We 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.
    2222
    23 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.
     23The 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.
    2424
    2525