wiki:FeddToDo

Version 3 (modified by faber, 16 years ago) (diff)

--

Fedd's Future

Fedd is the cornerstone of DETER's federation system, and is continually evolving to realize new parts of that architecture as well as making the realized parts more useful to users. As such, development is continually ongoing. This page captures the various design and development thrusts.

Research Goals

More sophisticated attribute-based authorization system
The current authorization system is attribute-based, but very simple. There is no facility for delegation or for auditing the authorization decisions that have been made. Furthermore, federated systems need to be able to model and influence the amount of data that partners share in making authorization decisions and to constrain the interactions necessary to authorize.

We plan to address these issues by developing an authorization system based on attributes and reasoning based on the ABAC system developed at 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 GENI.

Federation across dynamically configurable network infrastructure
Facilities like 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.
Federation-aware experiment design tools
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.
Advertisements and testbed information
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.
Appropriate federated environment
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.

Operational Features

More federant connection options
The current 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.
Moving away from ns2-based experiment descriptions
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.
Tuning the federated environment
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 SMB from 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 federation kit.