Banner
Whitepaper - On Federations...
Date produced: January 2009
Nature: Definition
Dissemination level: PU (Public)
Contact: If you want to react, send an e-mail to This e-mail address is being protected from spambots. You need JavaScript enabled to view it
PDF file pdf_button
Full text of whitepaper:

Federated testbeds are the cornerstone of the FIRE effort, yet the word "federation" is used in what appear to be different ways by the various present FIRE projects.  Perhaps some discussion of what the word means and the activities that it entails in the creation of technologies underlying the future Internet will be helpful in understanding present activities and in planning future FIRE projects.

The dictionary provides a definition of federation that emphasises the use of the word in its political or government context: "A federation is a union comprising a number of partially self-governing regions united by a central "federal" government under a common set of objectives."

This definition seems quite appropriate for the discussion of federating the resources available in networks, the networks themselves, and test environments for future styles of networking.  Most importantly, we note that the presence of common objectives defines a federation.  Without common objectives, a federation is meaningless.  In addition, some objectives may constrain the type of resources involved or the techniques used to combine them, making other objectives unfeasible.

Some of the potential objectives in networking for which federation is natural include:
  • Achieving scale
  • Achieving more realism in the prototype's operating environment
  • Access to specialised or diverse resources
  • Savings through sharing unused resources (or revenue from making them available)
  • Scientific gain through sharing resources, and creating a community
  • Scientific gain through exchanging results
  • Increasing geographic extent of the prototype
In addition to common objectives, there are a number of constraints that make the achievement of certain objectives difficult or even impossible. For example, many constraints arise through the usage context of a shared resource, e.g., the usage of particular sensor data in its acquisition context.  Thus reproducibility is often hard to achieve in a testbed intended to provide real-world variability.  A testbed which emphasises access to a broad scale or spatial distribution of inputs or environments may not easily extract information about each locality covered.  And the objective of achieving very large scale is difficult when the resources are extremely heterogeneous, as occurs in sensor networks and new types of wireless cells.

Achieving large scale in a shared resource is often accomplished by slicing, yet this will sacrifice reproducibility, the measurements are affected by interference from the unseen activities that take place in other slices sharing the resources. In addition, a central problem of high heterogeneity combined with large scale is the existence of bottleneck resources. For example, a wireless testbed allowing only for time slicing makes it almost impossible for long-term experiments to use it as part of a heterogeneous network topology. The existence of such bottleneck resources create scarcity, which is a problem that could be solved either through increased resource contributions (e.g., many wireless testbeds available) and/or sophisticated resource allocation policies (providing access based on payments or resource contributions).

Probably the most obvious source of conflict in these objectives is between the customers who benefit from scientific openness, and those for whom commercial constraints require keeping test results and test details confidential. Local governance rules and policies introduce constraints on federation. Examples are IPR, rules for dealing with human subjects, the requirement of funding to defray the costs of the resources, and policies regarding the exposure of information.  Privacy is a ubiquitous concern of this class, as is the confidentiality required when the research has immediate commercial impact. The complexity that arises when very diverse systems are integrated is always a restriction on the extent to which federation can be applied. This conflict highlights the difficulty of federating "commercial" and "non-commercial" facilities. It will also be worth exploring other possibilities where a "non-commercial" facility can "spin-off" a commercial one with a well-focussed target and application and the fulfilment of its user requirements (see for example the case of CoDeen or M-Lab in the PlanetLab constellation).

The existing FIRE projects have taken somewhat different approaches to federating the testbeds they presently involve.  Their differences can be traced to the fact that each supports different customers, who have different objectives.  We can analyse each of them to identify the constraints that result from their choices of objectives.

OneLab2, which has a research focus and uses open source software and toolkits, is primarily non-commercial. Because the results of its testbeds are archived and shared, governance issues arise only in allocating access to scarce resources.  The major tool of OneLab, an extended public and private collection of European PlanetLab slices, has little usage context dependence due to the nature of currently shared resources.  As wireless testbeds are added to its mix, this will change.  Also, sharing of controlled access to network bandwidth, in proposed collaborations with

Federica, will impose additional constraints due to the limited network facilities and portals involved.

Federica, initially, is free to the academic users whom it supports, but the finiteness of their resources has caused them to impose an access control governance structure.  Potential users make proposals, which are judged and prioritised.  Access is limited in duration as well as in bandwidth.  There is a strong possibility that Federica users will eventually have to pay for dedicated resources that they consume.

PanlabII (PII) supports a different set of customers, mostly industrial developers and researchers dealing with ideas which are closer to product or service realisation.  Governance issues are vital here, and have been a primary focus of the project, which has developed contractual terms and conditions for shared use of a wide range of specialised test beds.  In contrast to OneLab's customers, Panlab's customers have proprietary information and IP rights to protect, and do not expect to share the results of their experiments, which may be interoperability tests or customer focus group feedback.  Because of the disparate nature of the different testbeds they represent, scale to larger numbers of individual computing or networking units will be complex and difficult, but it may not be as important to that set of customers. PII could be viewed as an infrastructure provider (conceptually similar to Federica) which, in the best scenario, could provide access to its aggregated "commercial" testbeds to non-commercial users as well, if they wish to "pay the price". In that sense federation with PII is a customer-broker relationship.  PII playing the role of the broker for OneLab resources might be difficult to achieve as PII does not share the same objectives as OneLab (and vice-versa) and also because its allocation policy (market-based) is incompatible with the one currently used in OneLab (best-effort).

The above remarks motivate the need to discuss in more depth the various types and levels of federation that might exist together with their resource management policies. For that, let us consider the case of two independent testbeds federated into a larger one. The question is whether the users of the two federating authorities will have the same access rights to the aggregated federation resources or these will depend to the "value" of their authority's contribution to the federation.

An important parameter is whether an authority is associated with a specific set of users or not. For example, federating Federica with OneLab (or PlanetLab Europe [PLE]) is different conceptually than federating PLE with PlanetLab Central (PLC). In the first case, OneLab/PLE users are by default potential Federica users (they are a subset of them). And the federation would mean for them the ability to run their experiment across both platforms at the same time. So, the most important challenges are technical (resource specifications, APIs, etc.). When OneLab/PLE alone (or with Federica included) federates with PlanetLab (with other testbeds included) then "remote" users might need to have different access rights from the "local" ones. If a remote user wants to have access to Federica resources, through the federation of PLE with PLC, there exists a resource management problem that is very much alike that of the Internet but in a more general sense (since the set of resources is larger than mere routing resources that are shared in today's Internet). Hence, what is required for these cases of federation are "peering agreements", i.e., agreements on how to share particular resources across federations. And, similar to the transit and peering relations in the Internet, a tiered model of peering relations seems to be worth considering.

This situation is currently being considered in the PlanetLab constellation with federation at level 1 (highest level) between PLE, PLC and PLJ (Japan) while a federation at layer 2 is considered for integrating highly heterogeneous testbeds and therefore highly specialised and probably more access-controlled resources (for example, PLE with a small wireless testbed that has possibly a small number of associated users with it). Such small testbeds will be considered as "special" PLE sites that will be integrated into PLE's aggregated resources and will be subject to the local PLE's policies. Similarly, discussion with G-Lab concluded that, due to the restricted and controlled access to G-Lab resources, this testbed should better be federated at layer 2, therefore PLE delegating access to G-Lab for managing their own resources.

Summary

Federation was  introduced a few years ago as a means to benefit from various existing or future testbeds, increasing the benefit for the end user and the sustainability of diverse facilities. Nevertheless, it is important to note that a federation is defined by the presence of common objectives. Without common objectives, a federation is meaningless.

Moreover, different levels of federation should co-exist to take into account issues related to cost, complexity and context. Considering federation in a general case is certainly neither feasible nor meaningful if problems are to be solved within the FIRE framework.