Changes between Version 3 and Version 4 of FeddToDo
- Timestamp:
- Jun 30, 2010 3:07:18 AM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FeddToDo
v3 v4 10 10 We plan to address these issues by developing an authorization system based on attributes and reasoning based on the [http://www.isso.sparta.com/research_projects/security_infrastructure/abac.html ABAC] system developed at [http://www.sparta.com SPARTA]. In addition to the direct use in DETER, we plan to demonstrate the power of that system to address the needs of larger scale systems like [http://www.geni.net GENI]. 11 11 12 Federation across dynamically configurable network infrastructure::13 Facilities like [http://dragon.maxgigapop.net/twiki/bin/view/DRAGON/Network Dragon] offer the possibility of linking federated testbeds using guaranteed network resources, rather than best effort wide-area Internet connectivity. The DFA intends to make such resources available to experimenters - that is to enable capacity and topology guarantees between federants. Connecting federants with the same kinds of guarantees between federants as exist within federants will significantly enhance federation's utility.14 15 12 Federation-aware experiment design tools:: 16 13 [http://seer.isi.deterlab.net SEER] currently supports the creation and manipulation of federated experiments. This makes it possible for experimenters to access the power of federation, but to get the best use out of the capability, we believe that more sophisticated tools are essential. Such tools would either give users more detailed hints about how to break up experiments for federation or make those decisions for them (perhaps with an override). We are continuing to encourage the creation of such tools. … … 19 16 Currently the DFA and `fedd` do not provide a formal way for testbeds to describe their capabilities and policies. Currently this data is exchanged out of band and in an ad hoc way. As more testbeds with wider ranges of policies and capabilities make themselves federable, this ad hoc strategy will limit growth. We intend to formalize a system for exchange of this information and integrate it into future `fedd` releases. 20 17 21 Appropriate federated environment::22 The Emulab model for experimentation has proved useful as a guide for creating an environment in federated experiments that makes sense to users. However we believe that model will need to be extended as it leaves the confines of a single-room set of components into an environment where the number of elements to be controlled is greater and the latency to the controller is larger. To this end we are analyzing the features of the current environment to decide which can be moved into the federated environment directly, and which may need to be redesigned. Finally there are likely to be constructs that do not exist in the Emulab environment but that are necessary to deal with the scale and heterogeneity of federated experiments.23 18 24 19 == Operational Features == … … 27 22 The current [FeddAbout#TheFederationKit federation kit] establishes tunnels between the various federants using SSH tunnels that carry link layer packets. We plan to allow more options for experimenters, including IPSec tunnels, that will enable different interconnection properties between federants. This also interfaces with our desire to federate using dynamically configurable network resources. 28 23 29 Moving away from ns2-based experiment descriptions::30 While ns2 experiment descriptions have the significant advantage of making ns2 experiments easy to bring into testbeds, the language is troublesome in many ways. A simpler language that describes experiment topology and requirements without being Turing complete would simplify topology analysis. Also the security implications of executing programs in a full-featured language in order to extract topology are unfortunate. We intend to move from ns2's imperative model to a simple declarative model of network description.31 32 24 Tuning the federated environment:: 33 25 As part of our larger goal of building an experimental environment tuned for federated experiments, we are working to efficiently generalize and scale the parts of the existing environment that are conceptually useful but implemented for a local testbed. For example, providing a shared file system to many hosts in the wide area will be better accomplished with a file system designed for those goals. Our first step to the reliable-messaging and integrated authentication of [http://en.wikipedia.org/wiki/Server_Message_Block SMB] from [http://en.wikipedia.org/wiki/Network_File_System_(protocol) NFS] represents a first step toward a wide-area file system for federation. We intend to continue to improve these generalizations. These improvements are largely in the [FeddAbout#TheFederationKit federation kit]. 26 27 == Release Plans == 28 29 Release 3.1:: 30 [http://www.isso.sparta.com/research_projects/security_infrastructure/abac.html ABAC-enabled] release. Planned for October 2010 31 32 Release 4.0:: 33 Enhanced testbed service descriptions. Planned for Feb 2011.
