Service-Oriented Testbed Infrastructures and Cross-Domain

							Service-Oriented Testbed Infrastructures and Cross-Domain Federation for Future Internet Research
Thomas Magedanz1,2, Florian Schreiner1, Sebastian Wahle1
1

Fraunhofer Institute for Open Communication Systems (FOKUS), Germany {thomas.magedanz|florian.schreiner|sebastian.wahle}@fokus.fraunhofer.de
2

Technische Universität Berlin, Germany tm@cs.tu-berlin.de Furthermore, we currently observe a merger of classic telecommunication services and Internet style applications in the application domain. Concurrently, in the network domain, the convergence of networks is driven by the means of the Internet Protocol (IP) and the related change in the value chain draws new requirements upon service and network provisioning. Also, the increasing use of workflow-based service composition and service brokering in the applications space is mirrored by functional network composition where atomic service building blocks are combined in a flexible manner to support different requirements. This demands for advanced service description and orchestration techniques both in the application and network space. However, different technologies are required to serve the needs on the different layers. The paper is organized as follows. In section II we outline the main Future Internet drivers and their requirements and relate this to network and service oriented testbeds. Section III introduces the Network Domain Federation concept on a high and abstract level while section IV relates the abstract concept and its implications to testbeds. Section V describes a prototype implementation of the proposed concept and architecture. Section VI concludes the paper. II. NETWORK TESTBEDS VERSUS SERVICE ORIENTED TESTBEDS – MEETING FUTURE INTERNET REQUIREMENTS The evolution of the Internet can be described as the shift from a network between computing systems to serve the purposes of a small group of computing experts (in the 70s) to a global interconnection of communities and mass markets. As seen today, the main three pillars of the Future Internet are: • The Internet of Services • The Internet of Media/Content • The Internet of Things These pillars are grounded on different networks which form the infrastructure basement and are subject to network research and its related testbeds. However, the above mentioned pillars and their related research fields should be addressed by service oriented testbeds that take into account the high modularity [4] of both the network and the applications space of the Future Internet. The following subsections describe the Future Internet pillars in more detail.

Abstract—This article outlines the necessity for federated service oriented testbeds in order to accommodate the requirements of Future Internet research. Extensive investigations have been carried out in the networking and grid computing area during the last decades. These activities have successfully instantiated a number of large scale collaborative network testbeds and network emulation testbeds. The article describes an architectural approach on how to design service oriented testbeds and federate them across the boundaries of administrative domains to provide testing and development platforms that serve the needs of Future Internet research not only on the networking layer but also in the service and control platform layers. Index Terms—Federation, Future Internet, Network Domain Federation, SOA, Testing, Test Facilities

I. INTRODUCTION Extensive research has been carried out in the networking and grid computing domains for the past decades and a lot of important scientific contributions from the international research community have been made targeting these fields. The Internet has become the backbone of international activities and has changed the way we live, work, and communicate today. International business more than ever depends on this global network and we can witness the Internet to have a drastic impact on culture and commerce. This is the rather neutral way of looking upon the Internet as it is today. A more negative way of drawing the same picture would be: The Internet today is an unregulated, anonymous, unreliable, and insecure scene that provides the breeding ground for misuse and crime such as identity theft and scam. On order to improve this situation, a vast number of projects from industry and academia are under way worldwide. To validate and integrated their findings, large scale testbeds are needed and have been built and improved for the past years. Among those are mainly network and infrastructure testbeds such as PlanetLab [1], Emulab [2], Ultrascience Net [3] and others. Although network related research is an important field and its results are providing the substantial basis to support higher layer functionalities, it cannot address all issues related to the evolution of the Internet. The application space and its evolving requirements have to be taken into account as the main drivers for network evolution.

978-1-4244-3924-9/09/$25.00 c 2009 IEEE

101

Authorized licensed use limited to: FhI fur Offene Kommunikations-systeme. Downloaded on November 4, 2009 at 08:57 from IEEE Xplore. Restrictions apply.

A. The Internet of Services In recent years service oriented computing has heavily influenced the way of providing internet-scale applications. A most prominent example is the emergence of Web2.0 and the related application mashup phenomenon. Service orientation and service orchestration will be the dominating design paradigm for the Future Internet. The idea behind service orientation is to encapsulate atomic functionality and provide it as a service. Such services can be requested by humans or other services. This leads to a coupling of atomic functionalities into larger service blocks (or service chains) where a service can be composed by any number of other services. However, the services are “loosely coupled” meaning that any service provides functionality on its own and does not depend on any other service. In this way, service orchestration leads to composite applications that are a specific aggregation of a number of services that are offered by different independent sites. Furthermore, a considerable trend in industry is to link business processes and service oriented computing. This is what is commonly known as a Service Oriented Architecture (SOA) where business processes are represented by a workflow of specific loosely coupled services. B. The Internet of Media/Content Digital media is increasingly replacing analog media. This will eventually result in a complete digitalization of media (for example video) and content (for example books and magazines). Today it is difficult to cope with the amount of digital information being produced worldwide both by organizations (for example press) as well as end users (user generated content). This is mainly due to the lack of semantic interpretation of information and proper service discovery functionalities. A lot of research activities are currently under way to improve current approaches of semantic service and content annotation (tagging) and it is expected that inference systems will intelligently process the constantly increasing amount of available information and present it in an understandable and optimized way to different classes of requesters. C. The Internet of Things “Internet of Things” stands for the phenomenon that more and more “things” around us are electronically addressable and controllable. This trend is expected to continue and further increase. With IPv6, even today there is a huge addressing space available and many more things will be addressable in the future. Also, with the increased use of semantics and information abstraction, things are expected to self-organize and behave more intelligently. D. SOA-based Testbeds The above mentioned pillars of the Future Internet define the requirements drawn upon the experimental facilities, the testbeds that are needed to integrate and validate Future Internet research. Such testbeds need to be able to deal with the high abstraction and modularity of today’s and future networks. While today’s network layers might be irrelevant or

simplified in future networks, testbeds will more and more need to provide third parties with loosely coupled services and heterogeneous network and application layer functionalities upon demand in a highly flexible and combinational manner. They need to be able to integrate semantic frameworks in order to allow for automated service composition and the automated workflow management associated with complex application scenarios as well as network provisioning and control. In order to provide all the above mentioned capabilities, Future Internet research initiatives need to be aware of such requirements and carefully design experimental facilities that themselves adhere to the design principles of the Future Internet. From our perspective, most network research driven testbeds are lacking this. Therefore, we propose the further instantiation of SOA-based testbeds and especially a broker functionality that negotiates between existing initiatives and testbeds in order to offer the full range of network and application space services to interested parties. E. Related Work and Network Testbeds Currently, a number of research initiatives are addressing the need for large scale experimental facilities and the concept of federation on both a European and a worldwide scale. The European FIRE initiative (Future Internet Research & Experimentation, [5], [6]) seeks to create a dynamic, sustainable, large scale European Experimental Facility, which is built by federating existing and new testbeds in order to boost European innovation and its competitive role in defining Future Internet concepts. Projects worth mentioning here that target the FIRE objective of building a federated experimental facility are Onelab [7] and Federica [8]. Onelab builds upon PlanetLab [1], [9] software but aims at extending PlanetLab into new environments beyond the traditional wired internet (wireless extension), deepen PlanetLab’s monitoring capabilities, and provide a European administration for PlanetLab nodes in Europe (federation). The Federica project aims at creating an infrastructure for Future Internet research, allowing disruptive experiments in a short time frame using virtualization. The infrastructure relies on the multi-domain European National Research and Education Networks (NRENs) and the GÉANT2 [10] backbone. In the approach followed by Federica, virtualization is used to create “slices” from a physical substrate according to the user’s request. A slice is a set of virtual network and computing resources that can be created, allocated, and used simultaneously for experiments. Similar to the FIRE initiative in Europe, the US NSFfunded (United States National Science Foundation) GENI initiative (Global Environment for Network Innovations [11]) seeks to enable network science and engineering experiments by providing an experimental suite of network infrastructure. Federation also plays a central role in the overall GENI architecture [12] to allow for large scale experiments in heterogeneous environments. Several GENI projects are currently under way, which are organized in five competing clusters that will implement the prototype GENI control plane.

102

2009 IFIP/IEEE Intl. Symposium on Integrated Network Management — Workshops

Authorized licensed use limited to: FhI fur Offene Kommunikations-systeme. Downloaded on November 4, 2009 at 08:57 from IEEE Xplore. Restrictions apply.

Most projects rely on already existing software, namely the Emulab software [13] and the PlanetLab software [9]. The name Emulab refers to the Emulab project, the facility (testbed) and the software. The Emulab project maintains the facility. The Emulab facility uses the software, which is also used by numerous other testbeds to control their infrastructure. The Emulab software is enhanced by GENI cluster A and C to derive a GENI architecture [12] compatible control framework. The PlanetLab software is used by GENI cluster B and C. Currently, the implementation of a wrapper module is under way to support the GENI-defined interfaces and make the software compatible with the overall GENI system architecture. Further information on the GENI projects, their control framework and GENI spiral 1 achievements can be obtained in [11], [14], and [15]. In the following, we will describe a cross-layer and crossdomain network domain federation approach to federate distributed resources. This approach is currently implemented in the course of the PII project [17]. We will introduce the architecture and also give some early implementation results. The difference between our approach and the work described above is that we do not only focus on network testbeds but also incorporate more or less closed environments where precommercial product testing, interoperability testing and benchmarking can be carried out. This demands, apart from a technical concept, for a legal and operational framework to establish trust relationships between the different test sites, test users, and the federation organization itself. III. NETWORK DOMAIN FEDERATION APPROACH In the previous chapter we have outlined a number of requirements that need to be met by service oriented testbed infrastructures (whether they are federated or not) in order to cope with the complexity of today’s systems, the short development cycle, and Future Internet challenges. Our definition of federation in the context of sharing network resources is the following: Federation is a model for the establishment of a large scale and diverse infrastructure for communication technologies, services, and applications and can generally be seen as an interconnection of two or more independent administrative domains for the creation of a richer environment and for the increased multilateral benefits of the users of the individual domains. In the following, we describe the Network Domain Federation (NDF) model as shown in figure 1 and outline how this is suited to become the glue between both service oriented testbeds and network testbeds. The work presented here shall provide the fundament to prove that federation is a model for the establishment of a long-term sustainable large scale and diverse testing infrastructure for telecommunications technologies, services, and applications across the boundaries of administrative domains and technology layers. This will fundamentally serve the needs of Future Internet research and development. As shown in figure 1, the NDF model assumes that different administrative domains engage in a collaborative manner in order to share resources and services among each other and provide third parties access to their infrastructure.

A

SOA Service Composition
B

C

D

Business Entity Federation Control

Configuration, Test Execution and Mangement

Publish Capabilities, Services, Features and Results

M Domain
A B

M Domain
D E

M Domain
A B C

M Domain M Domain
B C D

Fig. 1. Network Domain Federation. The figure shows the general concept of Network Domain Federation where highly heterogeneous resources spread across distributed administrative domains can centrally be controlled.

All participating domains dispose of components that they are willing to provide to the federation and its users. Such components are depicted by the circles A, B, C, and D. We assume the components to be highly heterogeneous ranging from hardware resources (for example a router) over advanced software systems (for example an IP Multimedia Subsystem (IMS) signaling core network) to services (for example ParlayX services). We also assume that a domain might itself be distributed. An administrative domain might for example be represented by the Federica project [8] that is willing to share Federica “slices” following the NDF concept. Each domain disposes of a Domain Manager component depicted by the squares labeled with “M” in figure 1 that translates federation level messages to resource specific communication. This is a crucial part for the entire concept. The NDF model assumes that between all participating domains a common control plane has been established that uses generic commands and messages to control the distributed resources. This means that the Domain Manager need to be able to understand the federation level signaling and translate this to resource specific commands that might be standardized or proprietary. This approach assures that despite the very high heterogeneity in the domains and their offered resources, a high level composition of a desired infrastructure (across several domains) can be achieved. In other words: one manager needs to be implemented per administrative domain and each Domain Manager needs to be able to provision the corresponding domain resources on demand if requested via the common control plane. This is where resources become services to be consumed by the federation and its users. The services offered by the managers take as parameters the necessary information that is needed to successfully provision and configure the resources. Figure 1 also displays a business entity. This is an organization that legally represents the federation. Different business models are possible to operate a NDF. The two most obvious ones are a regulated approach contrasting the market approach. An example for a regulated approach would be a federation where everybody that contributes resources is

2009 IFIP/IEEE Intl. Symposium on Integrated Network Management — Workshops

103

Authorized licensed use limited to: FhI fur Offene Kommunikations-systeme. Downloaded on November 4, 2009 at 08:57 from IEEE Xplore. Restrictions apply.

allowed to make use of the entire pool of resources within the federation. The market approach would require the users to be charged upon usage of federation resources. This would allow participating domains to generate revenues and ultimately lead towards a service market where different domains compete against each other. The NDF model is able to support both approaches, also in a combined manner. Another crucial issue regarding the NDF concept is that optimally a common information model (such as TMF SID [16]) or other means (such as an ontology) to represent a common federation vocabulary would need to be used across the entire federation. This would require participating domains not only to implement a Domain Manager mapping federation control plane communication to their specific infrastructure but also adhere to a common information model. As this might be achieved for a few domains that commonly agree to collaborate, this approach does not scale to a global level. Solutions for this issue are a mapping between different models or between domain specific description languages and the common model, the extension of the federation model, and a high degree of abstraction on the federation level that can be broken down into specific data models depending on the specific domain. In summary, the NDF model makes use of the following concepts that meet the requirements defined before: • Defines a broker that can combine services offered by different domains to meet the requestors requirements. • Service orientation: Infrastructure offered by the domains becomes a service. Domain Managers implement the necessary wrapper functionality that hides testbed specific complexity and enables a unified federation control plane. • Abstraction: the federation level abstracts from resource specific aspects. This requires a solid model on the federation level on how to describe and invoke a service/resource. • Loose Coupling: The domains are separate functional entities and completely independent from each other. They can be used without and within a federation context. The proposed NDF model is currently being implemented within the PII project [17]. The control plane will rely on Web Services using Hypertext Transfer Protocol (HTTP) and Simple Object Access Protocol (SOAP). As the realization of the NDF concept requires several challenges to be overcome and since especially the field of service composition and semantic description is still subject to extensive research, it is foreseen that initial implementation phases will rely on many manual processes, while fully automated service composition remains the grand vision to be achieved in later concept implementation stages. IV. FEDERATION ARCHITECTURE This section will give more details of the proposed federation architecture in terms of concrete reference point (RP) descriptions.

Fig. 2. Federation Architecture Reference Points. The figure shows the reference points as defined by our federation architecture. They are grouped (T, U and I) according to their positioning within the overall architecture.

Figure 2 depicts the architecture with its interfaces and RPs. Note that in the following the federation control will be referenced by its main tool named Teagle, which, among other functionalities, allows for resource lookup and provisioning. For a more detailed description of Teagle, please refer to [18]. The RPs shall define the interfaces between the most relevant functional blocks as introduced by the NDF approach in the previous section. In the following, the more general and abstract NDF approach will be mapped to the use case of testbeds where the domains actually represent autonomously administrated testbeds and the federation control is represented by the Teagle tool. A. Reference Point T1 This Domain Manager interface exposes provisioning and configuration tasks towards the federation control (Teagle). The domain manger provides the mapping from unified control commands (issued by Teagle) to resource specific commands (to be received by the testbed components). Teagle uses this interface to provision and configure resources. The Domain Manager provides the necessary abstraction that is required to deal with the huge variety of possible testbed components and large number of protocols and commands supported by the individual components. This interface is also used to bootstrap interconnection between testbed resources residing in different testbeds. This means that the Domain Manager exposes interconnection setup functionality in the same way, other testbed resource provisioning and configuration functions are exposed. The following list of functions must be exposed by a Domain Manager: • Inter-testbed connection setup, configuration, and deactivation • Resource provisioning and de-provisioning • Query component status • Resource lookup The interface defined by RP T1 shall be a Web Service interface. Most common usage of Web Services is in a clientserver fashion where both communicate using eXtensible Markup Language (XML) messages that follow the SOAP

104

2009 IFIP/IEEE Intl. Symposium on Integrated Network Management — Workshops

Authorized licensed use limited to: FhI fur Offene Kommunikations-systeme. Downloaded on November 4, 2009 at 08:57 from IEEE Xplore. Restrictions apply.

standard. Usually, the SOAP endpoints and the available operations are described by Web Services Description Language (WSDL) documents. As HTTP is usually used as transport protocol which is not blocked by most firewalls, Web Services provide a well established means to communicate between different administrative domains. The interface shall be secured by application layer security mechanisms, for example using standard Web Service Security mechanisms. B. Reference Point T2 The Domain Manager implements an extensible layer that allows the dynamic installation of specific Resource Adaptors. Each Resource Adaptor (RA) translates common instructions into the specific protocols implemented by one or more testbed components. Therefore, the T2 interface is actually implemented by each RA independently, as required by the peculiarities of the associated testbed components in order to cope with the heterogeneity of the underlying testbed resources. Not all testbed components will need to support the whole set of control, management, and test result retrieving functionalities supported by the Domain Manager. Each Testbed component will have to implement the functionalities allowed by its nature and required by its intended. Standard management protocols (for example Simple Network Management Protocol (SNMP)) will be supported and provided by some default RAs. However, proprietary interfaces will need to be supported by specifically developed RAs. Since the presented architectural approach is generic in order to consider any possible underlying technology as testbed components (thus, providing flexibility to federate heterogeneous testbeds), the specific technologies to be used for the T2 interface are not fixed. The following general command types should be supported by the T2 Interface: • Resource discovery • Resource status • Configuration • Monitoring • Security • Quality assurance • Collection of test results • Tear down and de-provisioning C. Reference Point U1 This RP is the entry point for federation customers to interact with the federation control plane. It allows the customer to access the Teagle tool in order to request operations related with four main aspects: • Obtaining information on testbeds and associated resources • Transparently customizing and managing a testbed environment • Accessing and managing test results • Obtain contact information for testbed and federation responsible

D. Reference Point U2 This RP defines an interface that is used by the end- or testuser to do the actual testing. It provides direct access to the test resource in the resource natural way, using the resource’s typical interfaces. The user domain can be any network, including the Internet that is able to access the gateway (see figure 2). Technically, U2 is a “filtered window” of an internal testbed resource that needs to be exposed to the tester or user by the gateway using techniques like packet forwarding, application proxying, and/or network address translation. Which kind of access and filtering is used depends on the service that should be made accessible and was set up using Teagle. The task of the gateway at interface U2 is to ensure the availability of testbed resources in a secure manner without the loss of functionality. E. Reference Point U3 Access from the customer’s machine or lab network to the Virtual Customer Testbed (VCT) is granted by the gateway. This connection utilizes standard secure “dial in” technologies, such as Internet Protocol Security (IPSec), Point to Point Tunneling Protocol (PPTP), and Layer 2 Tunneling Protocol (L2TP). The gateway manages access limitations to the VCT associated resources that have been set up by the customer using Teagle. The customer uses a standard Virtual Private Network (VPN) client or VPN aware router to directly connect to a VPN concentrator (usually a gateway chosen by Teagle) to become part of his VCT. Once interconnected, the customer is able to address “rented” resources including configuration front-ends. Please note that at the moment the customer initiates an actual testing session, he becomes an end user (therefore using ref. point U2) in our architectural terminology. In this case he might or might not use a VPN client to connect to resources, as via U2, the natural resource interfaces can be accessed. F. Reference Point I1 The interface defined by I1 provides a gateway-to-gateway connection, a data path between two testbeds. Communication between the gateways uses the data plane only, there is no control message exchange since the secure tunneling methods are stateless and use pre-shared secrets. Routing between testbed components of different testbeds is done by the gateway using intelligent routing protocols like Open Shortest Path First (OSPF) and topology information, including VPN setup parameters transmitted by Teagle through the Domain Manager. Using the I1 interface, all gateways can form a meshed testbed interconnection network that is dynamically created without exchange or stateful control G. Reference Point I2 The interconnection between a local gateway and the internal testbed components is defined by the I2 RP. The main purpose of this is to enable an isolated (e.g. by Virtual Local Area Network (VLAN) techniques) link layer access to all associated testbed components and Quality of Service (QoS) based traffic shaping for traffic that is routed from the testbed component through the gateway. To achieve a secure and

2009 IFIP/IEEE Intl. Symposium on Integrated Network Management — Workshops

105

Authorized licensed use limited to: FhI fur Offene Kommunikations-systeme. Downloaded on November 4, 2009 at 08:57 from IEEE Xplore. Restrictions apply.

isolated connection between a gateway and testbed components, the latter need to be directly connected to the gateway or link layer by a switching device that honors link layer isolation methods like IEEE 802.1q (VLAN). As long as the associated testbed component is assigned to a VCT, the associated gateway shall have exclusive link layer access for reliability and security reasons. V. PROTOTYPE IMPLEMENTATION A first prototype implementation of the proposed architecture has been realized and is currently being extended. T1 has been implemented making use of the Service Provisioning Markup Language (SPML) and uses HTTP, SOAP and XML to convey provisioning messages from Teagle via a Domain Manager to a presence server and a XML Document Management Server (XDMS). The current implementation allows the remote setup, configuration, and tear-down of the two server components. As part of a demonstration scenario, two IMS domains (in Greece, University of Patras and in Germany, Fraunhofer FOKUS) based on the Fraunhofer Open IMS Core [19] have been interconnected using a VPN IPSec tunnel. IMS clients have been registered at both domains but only one domain (Fraunhofer FOKUS) was controlled by a Domain Manager. Using our first implementation of Teagle [20], the presence server and XDMS can be provisioned via the Domain Manager. This allows the clients connected and registered in both domains to make use of the functionalities offered by the two server components (group/contacts list via the XDMS and presence status of the contacts via the presence server) upon request. T2 has been implemented mapping the T1 message commands to XML Configuration Access Protocol (XCAP) messages, Session Initiation Protocol (SIP) messages, and shell commands providing two simple RAs. In the current implementation, U1 allows the lookup of resources and simple provisioning. On U2 and U3 usual IMS communication messages (for example SIP and Real-Time Transport Protocol (RTP)) can be exchanged as defined by 3GPP using standard conformant IMS clients. The other architecture RPs have not been the main target of our first implementation and will be realized in future versions of the architecture implementation. The scenario shows that the NDF (and the concrete testbed use case) paves the way for new business models for testbed providers. For example, in our scenario, the Greek testbed was enhanced with additional functionality (offered by resources that are physically located in the Fraunhofer FOKUS testbed in Berlin) using the NDF approach. This makes the Greek testbed more attractive for local testing customers in Greece that are seeking to test application and client scenarios involving group/contacts lists and presence status. VI. CONCLUSION AND OUTLOOK The paper describes an architecture on how to federate arbitrary network domains and their resources. Other related research activities in the field have been discussed before a detailed insight into the proposed architecture and its reference

points was given. The experience gained from implementing our first prototype will guide the upcoming activities. In order to allow for a more automated solution we need to find a way to uniformly describe the involved domain resources. This will be very challenging given the high heterogeneity of resources the system needs to deal with. Future efforts will therefore be centered around using a common and abstract way of representing the resources on the federation control level. This shall allow for domain specific languages and models to be used for different domains and to be mapped accordingly. ACKNOWLEDGMENT Parts of this paper are based on work and ideas generated in the course of the project PII [17], which receives funding from the European Commission’s Seventh Framework Programme (FP7). REFERENCES
[1] [2] Chun, B. et al.: PlanetLab: an overlay testbed for broad-coverage services. SIGCOMM Comput. Commun. Rev. 33, 3 (Jul. 2003), 3-12. B. White et al.: An integrated experimental environment for distributed systems and networks. Proc. 5th Symp. on Operating Systems Design and Impl. 255–270 (2002) Rao, N.S.V., Wing, W.R., Carter, S.M., Wu, Q.: Ultrascience net: network testbed for large-scale science applications. Communications Magazine, IEEE, vol.43, no.11, pp. S12-S17, 2005 Florian Schreiner, Sebastian Wahle, Niklas Blum, and Thomas Magedanz: Modular Exposure of Next Generation Network Services to Enterprises and Testbed Federations. Second International Conference on Communications and Electronics, HUT-ICCE 2008, pp 98 – 103, IEEE (2008) Future Internet Research & Experimentation (FIRE) Initiative website, http://cordis.europa.eu/fp7/ict/fire/ Gavras, A., Karila, A., Fdida, S., May, M., and Potts, M. 2007. Future internet research and experimentation: the FIRE initiative. SIGCOMM Comput. Commun. Rev. 37, 3 (Jul. 2007), 89-92. OneLab project website, http://www.onelab.eu/ Federica project website, http://www.fp7-federica.eu/ PlanetLab website, http://www.planet-lab.org/ GÉANT2 website http://www.geant2.net/ Global Environment for Network Innovations initiative website, http://www.geni.net/ GENI Project Office, GENI System Overview, Document ID: GENISE-SY-SO-02.0, September 29, 2008, http://www.geni.net/docs/GENISysOvrvw092908.pdf Emulab project and testbed website, http://emulab.net/ GENI Project Office, GENI Spiral 1 Overview, Document ID: GENIFAC-PRO-S1-OV-1.12, September 29, 2008, http://www.geni.net/docs/GENIS1Ovrvw092908.pdf GENI Project Office, GENI Control Framework Architecture, Document ID: GENI-ARCH-CP-01.4, October 20, 2008, http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkArch itecture/102008_GENI-ARCH-CP-01.4.pdf TeleManagement Forum, NGOSS SID, http://www.tmforum.org/TechnicalPrograms/NGOSSSID/1684/Home.ht ml , 2008 PII project website: http://panlab.net Sebastian Wahle et al.: Technical Infrastructure for a Pan-European Federation of Testbeds. In TRIDENTCOM 2009, Washington DC, USA, April 2009. IEEE. Accepted for publication in 2009, ISBN: 978-1-42442847-2, IEEE Catalog Number: CFP09364. Open Source IMS Core website, http://www.openimscore.org Teagle website, http://www.fire-teagle.org

[3]

[4]

[5] [6]

[7] [8] [9] [10] [11] [12]

[13] [14]

[15]

[16]

[17] [18]

[19] [20]

106

2009 IFIP/IEEE Intl. Symposium on Integrated Network Management — Workshops

Authorized licensed use limited to: FhI fur Offene Kommunikations-systeme. Downloaded on November 4, 2009 at 08:57 from IEEE Xplore. Restrictions apply.