Changes between Version 6 and Version 7 of LayoutAspect
- Timestamp:
- Oct 15, 2013 11:50:38 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
LayoutAspect
v6 v7 3 3 = Describing And Manipulating Experiment Topologies in DETER = 4 4 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 topologies of its control and data networks.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. 6 6 7 Because DETER experiments are intended to be large - thousands or millions of entities - DETER's topology system must support large scale 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. 8 8 9 * Specification 10 * Operations - realize, initialize, etc. 11 * Visualization 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. 10 11 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. 12 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. 14 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. 12 16 13 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. … … 15 19 == Model == 16 20 17 === The Basic Model === 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. 22 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. 24 25 26 === The View Model === 27 28 Each view is a description of a topology, and we begin by explaining how to describe such a topology, from simple, explicit descriptions, to more scalable and versatile versions. 29 30 ==== The Fundamental Topology Model === 18 31 19 32 A DETER topology is a collection of experimental elements that can communicate with one another. The topology model consists of ''elements'' that represent those experimental entities and ''substrates'' which indicate the valid commuincations scopes. An element may be specialized depending on the capabilities supplied or required. A substrate includes limits on how the communication rate and delay when communicating through it. … … 37 50 This also shows the bipartite nature of the graph. Substrates (blue ellipses) are only connected to computers/elements (green rounded rectangles). All interfaces connect an element to a substrate. 38 51 39 === Scaling Using Regions and Fragments===52 ==== Scaling Using Regions and Fragments ==== 40 53 41 54 The basic model specifies communication networks at a fairly high degree of abstraction while maintaining mechanisms for specialization. However, large topologies present several problems: … … 67 80 [[Image(Expanded.png)]] 68 81 69 === Recursive Regions===82 ==== Recursive Regions ==== 70 83 71 84 Fragments can contain regions, so topology descriptions can be recursive. These topology descriptions are used to allocate testbed resources, so the model insures that all recursions terminate. Each region is assigned a non-negative integer valued level. The outermost specification of topology can has region levels assigned by the user. When a region is inserted into a topology as a member of a fragment that replaces a region, we assign all regions in that replacement a level one less than the region that was expanded. … … 91 104 [[Image(Recursion3.png)]] 92 105 93 === Naming and Recursion===106 ==== Naming and Recursion ==== 94 107 95 108 We have been vague about how names are assigned to elements and substrates in recursions. In the simplest case, where the topology specifier does not care how those names are assigned, they can be assigned by the testbed (or tool). If the user wants a specific layout of names the pathname system can be used. … … 101 114 The model supports hybrid solutions, where some areas of a topology include user-specified name maps and some regions of the topology are named by the testbed (or tool). The rule is that testbed-assigned names are provisional and can be overriden by specific user assignments. 102 115 103 === Views ===116 === Multiple Views === 104 117 105 The previous sections have described topologies mostly in terms of constructing them, but a significant part of the model's power is in its ability to present topologies in different ways for different audiences.106 118 107 Consider the following scenario: a researcher studying the propagation of a security compromise makes use of a recursive tool to create a topology that reflects a particular scenario for study. Because it was generated by a recursive tool, a natural representation is in recursive regions, but those regions may not be useful to the researcher.108 119 109 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 elements (including regions) and substrates where the regions are defined, not by the workings of the construction algorithm, but by the semantics of the researcher's experiment.110 111 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 regions that map to physcial machines in the testbed.112 113 We call these different descriptions of the same topology ''
