Get documents about "Service-Oriented Testbed Infrastructures and Cross-Domain
Document Sample
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
Abstract—This article outlines the necessity for federated Furthermore, we currently observe a merger of classic
service oriented testbeds in order to accommodate the telecommunication services and Internet style applications in
requirements of Future Internet research. Extensive the application domain. Concurrently, in the network domain,
investigations have been carried out in the networking and grid
the convergence of networks is driven by the means of the
computing area during the last decades. These activities have
successfully instantiated a number of large scale collaborative Internet Protocol (IP) and the related change in the value chain
network testbeds and network emulation testbeds. The article draws new requirements upon service and network
describes an architectural approach on how to design service provisioning. Also, the increasing use of workflow-based
oriented testbeds and federate them across the boundaries of service composition and service brokering in the applications
administrative domains to provide testing and development space is mirrored by functional network composition where
platforms that serve the needs of Future Internet research not
atomic service building blocks are combined in a flexible
only on the networking layer but also in the service and control
platform layers. manner to support different requirements. This demands for
advanced service description and orchestration techniques
Index Terms—Federation, Future Internet, Network Domain both in the application and network space. However, different
Federation, SOA, Testing, Test Facilities technologies are required to serve the needs on the different
layers.
I. INTRODUCTION The paper is organized as follows. In section II we outline
Extensive research has been carried out in the networking and the main Future Internet drivers and their requirements and
grid computing domains for the past decades and a lot of relate this to network and service oriented testbeds. Section III
important scientific contributions from the international introduces the Network Domain Federation concept on a high
research community have been made targeting these fields. and abstract level while section IV relates the abstract concept
The Internet has become the backbone of international and its implications to testbeds. Section V describes a
activities and has changed the way we live, work, and prototype implementation of the proposed concept and
communicate today. International business more than ever architecture. Section VI concludes the paper.
depends on this global network and we can witness the
Internet to have a drastic impact on culture and commerce. II. NETWORK TESTBEDS VERSUS SERVICE ORIENTED
This is the rather neutral way of looking upon the Internet as it TESTBEDS – MEETING FUTURE INTERNET REQUIREMENTS
is today. A more negative way of drawing the same picture The evolution of the Internet can be described as the shift
would be: The Internet today is an unregulated, anonymous, from a network between computing systems to serve the
unreliable, and insecure scene that provides the breeding purposes of a small group of computing experts (in the 70s) to
ground for misuse and crime such as identity theft and scam. a global interconnection of communities and mass markets. As
On order to improve this situation, a vast number of projects seen today, the main three pillars of the Future Internet are:
from industry and academia are under way worldwide. To • The Internet of Services
validate and integrated their findings, large scale testbeds are • The Internet of Media/Content
needed and have been built and improved for the past years. • The Internet of Things
Among those are mainly network and infrastructure testbeds These pillars are grounded on different networks which
such as PlanetLab [1], Emulab [2], Ultrascience Net [3] and form the infrastructure basement and are subject to network
others. Although network related research is an important field research and its related testbeds. However, the above
and its results are providing the substantial basis to support mentioned pillars and their related research fields should be
higher layer functionalities, it cannot address all issues related addressed by service oriented testbeds that take into account
to the evolution of the Internet. The application space and its the high modularity [4] of both the network and the
evolving requirements have to be taken into account as the applications space of the Future Internet. The following
main drivers for network evolution. subsections describe the Future Internet pillars in more detail.
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 simplified in future networks, testbeds will more and more
In recent years service oriented computing has heavily need to provide third parties with loosely coupled services and
influenced the way of providing internet-scale applications. A heterogeneous network and application layer functionalities
most prominent example is the emergence of Web2.0 and the upon demand in a highly flexible and combinational manner.
related application mashup phenomenon. Service orientation They need to be able to integrate semantic frameworks in
and service orchestration will be the dominating design order to allow for automated service composition and the
paradigm for the Future Internet. The idea behind service automated workflow management associated with complex
orientation is to encapsulate atomic functionality and provide application scenarios as well as network provisioning and
it as a service. Such services can be requested by humans or control.
other services. This leads to a coupling of atomic In order to provide all the above mentioned capabilities,
functionalities into larger service blocks (or service chains) Future Internet research initiatives need to be aware of such
where a service can be composed by any number of other requirements and carefully design experimental facilities that
services. However, the services are “loosely coupled” meaning themselves adhere to the design principles of the Future
that any service provides functionality on its own and does not Internet. From our perspective, most network research driven
depend on any other service. In this way, service orchestration testbeds are lacking this. Therefore, we propose the further
leads to composite applications that are a specific aggregation instantiation of SOA-based testbeds and especially a broker
of a number of services that are offered by different functionality that negotiates between existing initiatives and
independent sites. Furthermore, a considerable trend in testbeds in order to offer the full range of network and
industry is to link business processes and service oriented application space services to interested parties.
computing. This is what is commonly known as a Service E. Related Work and Network Testbeds
Oriented Architecture (SOA) where business processes are
Currently, a number of research initiatives are addressing
represented by a workflow of specific loosely coupled
the need for large scale experimental facilities and the concept
services.
of federation on both a European and a worldwide scale.
B. The Internet of Media/Content The European FIRE initiative (Future Internet Research &
Digital media is increasingly replacing analog media. This Experimentation, [5], [6]) seeks to create a dynamic,
will eventually result in a complete digitalization of media (for sustainable, large scale European Experimental Facility, which
example video) and content (for example books and is built by federating existing and new testbeds in order to
magazines). Today it is difficult to cope with the amount of boost European innovation and its competitive role in defining
digital information being produced worldwide both by Future Internet concepts. Projects worth mentioning here that
organizations (for example press) as well as end users (user target the FIRE objective of building a federated experimental
generated content). This is mainly due to the lack of semantic facility are Onelab [7] and Federica [8].
interpretation of information and proper service discovery Onelab builds upon PlanetLab [1], [9] software but aims at
functionalities. A lot of research activities are currently under extending PlanetLab into new environments beyond the
way to improve current approaches of semantic service and traditional wired internet (wireless extension), deepen
content annotation (tagging) and it is expected that inference PlanetLab’s monitoring capabilities, and provide a European
systems will intelligently process the constantly increasing administration for PlanetLab nodes in Europe (federation).
amount of available information and present it in an The Federica project aims at creating an infrastructure for
understandable and optimized way to different classes of Future Internet research, allowing disruptive experiments in a
requesters. short time frame using virtualization. The infrastructure relies
on the multi-domain European National Research and
C. The Internet of Things Education Networks (NRENs) and the GÉANT2 [10]
“Internet of Things” stands for the phenomenon that more backbone. In the approach followed by Federica, virtualization
and more “things” around us are electronically addressable is used to create “slices” from a physical substrate according
and controllable. This trend is expected to continue and further to the user’s request. A slice is a set of virtual network and
increase. With IPv6, even today there is a huge addressing computing resources that can be created, allocated, and used
space available and many more things will be addressable in simultaneously for experiments.
the future. Also, with the increased use of semantics and Similar to the FIRE initiative in Europe, the US NSF-
information abstraction, things are expected to self-organize funded (United States National Science Foundation) GENI
and behave more intelligently. initiative (Global Environment for Network Innovations [11])
D. SOA-based Testbeds seeks to enable network science and engineering experiments
by providing an experimental suite of network infrastructure.
The above mentioned pillars of the Future Internet define Federation also plays a central role in the overall GENI
the requirements drawn upon the experimental facilities, the architecture [12] to allow for large scale experiments in
testbeds that are needed to integrate and validate Future heterogeneous environments. Several GENI projects are
Internet research. Such testbeds need to be able to deal with currently under way, which are organized in five competing
the high abstraction and modularity of today’s and future clusters that will implement the prototype GENI control plane.
networks. While today’s network layers might be irrelevant or
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 SOA Service Composition
A C D
Emulab software [13] and the PlanetLab software [9]. B
Business Entity
The name Emulab refers to the Emulab project, the facility Federation Control
(testbed) and the software. The Emulab project maintains the
facility. The Emulab facility uses the software, which is also Configuration, Test Execution Publish Capabilities, Services,
used by numerous other testbeds to control their infrastructure. and Mangement Features and Results
The Emulab software is enhanced by GENI cluster A and C to
derive a GENI architecture [12] compatible control M M
framework. The PlanetLab software is used by GENI cluster B Domain Domain
and C. Currently, the implementation of a wrapper module is A B D E
under way to support the GENI-defined interfaces and make
M M
Domain Domain
the software compatible with the overall GENI system A B C D
M
architecture. Further information on the GENI projects, their Domain
control framework and GENI spiral 1 achievements can be B C
obtained in [11], [14], and [15].
In the following, we will describe a cross-layer and cross- Fig. 1. Network Domain Federation. The figure shows the general concept of
Network Domain Federation where highly heterogeneous resources spread
domain network domain federation approach to federate across distributed administrative domains can centrally be controlled.
distributed resources. This approach is currently implemented
in the course of the PII project [17]. We will introduce the All participating domains dispose of components that they
architecture and also give some early implementation results. are willing to provide to the federation and its users. Such
The difference between our approach and the work described components are depicted by the circles A, B, C, and D. We
above is that we do not only focus on network testbeds but assume the components to be highly heterogeneous ranging
also incorporate more or less closed environments where pre- from hardware resources (for example a router) over advanced
commercial product testing, interoperability testing and software systems (for example an IP Multimedia Subsystem
benchmarking can be carried out. This demands, apart from a (IMS) signaling core network) to services (for example
technical concept, for a legal and operational framework to ParlayX services). We also assume that a domain might itself
establish trust relationships between the different test sites, test be distributed. An administrative domain might for example
users, and the federation organization itself. be represented by the Federica project [8] that is willing to
share Federica “slices” following the NDF concept.
III. NETWORK DOMAIN FEDERATION APPROACH Each domain disposes of a Domain Manager component
In the previous chapter we have outlined a number of depicted by the squares labeled with “M” in figure 1 that
requirements that need to be met by service oriented testbed translates federation level messages to resource specific
infrastructures (whether they are federated or not) in order to communication. This is a crucial part for the entire concept.
cope with the complexity of today’s systems, the short The NDF model assumes that between all participating
development cycle, and Future Internet challenges. domains a common control plane has been established that
Our definition of federation in the context of sharing uses generic commands and messages to control the
network resources is the following: Federation is a model for distributed resources. This means that the Domain Manager
the establishment of a large scale and diverse infrastructure for need to be able to understand the federation level signaling
communication technologies, services, and applications and and translate this to resource specific commands that might be
can generally be seen as an interconnection of two or more standardized or proprietary. This approach assures that despite
independent administrative domains for the creation of a the very high heterogeneity in the domains and their offered
richer environment and for the increased multilateral benefits resources, a high level composition of a desired infrastructure
of the users of the individual domains. (across several domains) can be achieved. In other words: one
In the following, we describe the Network Domain manager needs to be implemented per administrative domain
Federation (NDF) model as shown in figure 1 and outline how and each Domain Manager needs to be able to provision the
this is suited to become the glue between both service oriented corresponding domain resources on demand if requested via
testbeds and network testbeds. The work presented here shall the common control plane. This is where resources become
provide the fundament to prove that federation is a model for services to be consumed by the federation and its users. The
the establishment of a long-term sustainable large scale and services offered by the managers take as parameters the
diverse testing infrastructure for telecommunications necessary information that is needed to successfully provision
technologies, services, and applications across the boundaries and configure the resources.
of administrative domains and technology layers. This will Figure 1 also displays a business entity. This is an
fundamentally serve the needs of Future Internet research and organization that legally represents the federation. Different
development. As shown in figure 1, the NDF model assumes business models are possible to operate a NDF. The two most
that different administrative domains engage in a collaborative obvious ones are a regulated approach contrasting the market
manner in order to share resources and services among each approach. An example for a regulated approach would be a
other and provide third parties access to their infrastructure. 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 Fig. 2. Federation Architecture Reference Points. The figure shows the
be achieved for a few domains that commonly agree to reference points as defined by our federation architecture. They are grouped
collaborate, this approach does not scale to a global level. (T, U and I) according to their positioning within the overall architecture.
Solutions for this issue are a mapping between different
Figure 2 depicts the architecture with its interfaces and RPs.
models or between domain specific description languages and
Note that in the following the federation control will be
the common model, the extension of the federation model, and
referenced by its main tool named Teagle, which, among other
a high degree of abstraction on the federation level that can be
functionalities, allows for resource lookup and provisioning.
broken down into specific data models depending on the
For a more detailed description of Teagle, please refer to [18].
specific domain.
The RPs shall define the interfaces between the most
In summary, the NDF model makes use of the following
relevant functional blocks as introduced by the NDF approach
concepts that meet the requirements defined before:
in the previous section. In the following, the more general and
• Defines a broker that can combine services offered by
abstract NDF approach will be mapped to the use case of
different domains to meet the requestors requirements.
testbeds where the domains actually represent autonomously
• Service orientation: Infrastructure offered by the administrated testbeds and the federation control is
domains becomes a service. Domain Managers represented by the Teagle tool.
implement the necessary wrapper functionality that
hides testbed specific complexity and enables a unified A. Reference Point T1
federation control plane. This Domain Manager interface exposes provisioning and
• Abstraction: the federation level abstracts from configuration tasks towards the federation control (Teagle).
resource specific aspects. This requires a solid model The domain manger provides the mapping from unified
on the federation level on how to describe and invoke a control commands (issued by Teagle) to resource specific
service/resource. commands (to be received by the testbed components). Teagle
• Loose Coupling: The domains are separate functional uses this interface to provision and configure resources. The
entities and completely independent from each other. Domain Manager provides the necessary abstraction that is
They can be used without and within a federation required to deal with the huge variety of possible testbed
context. components and large number of protocols and commands
The proposed NDF model is currently being implemented supported by the individual components. This interface is also
within the PII project [17]. The control plane will rely on Web used to bootstrap interconnection between testbed resources
Services using Hypertext Transfer Protocol (HTTP) and residing in different testbeds. This means that the Domain
Simple Object Access Protocol (SOAP). As the realization of Manager exposes interconnection setup functionality in the
the NDF concept requires several challenges to be overcome same way, other testbed resource provisioning and
and since especially the field of service composition and configuration functions are exposed. The following list of
semantic description is still subject to extensive research, it is functions must be exposed by a Domain Manager:
foreseen that initial implementation phases will rely on many • Inter-testbed connection setup, configuration, and
manual processes, while fully automated service composition deactivation
remains the grand vision to be achieved in later concept • Resource provisioning and de-provisioning
implementation stages. • Query component status
• Resource lookup
IV. FEDERATION ARCHITECTURE The interface defined by RP T1 shall be a Web Service
This section will give more details of the proposed interface. Most common usage of Web Services is in a client-
federation architecture in terms of concrete reference point server fashion where both communicate using eXtensible
(RP) descriptions. 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 D. Reference Point U2
operations are described by Web Services Description This RP defines an interface that is used by the end- or test-
Language (WSDL) documents. As HTTP is usually used as user to do the actual testing. It provides direct access to the
transport protocol which is not blocked by most firewalls, test resource in the resource natural way, using the resource’s
Web Services provide a well established means to typical interfaces. The user domain can be any network,
communicate between different administrative domains. including the Internet that is able to access the gateway (see
The interface shall be secured by application layer security figure 2). Technically, U2 is a “filtered window” of an internal
mechanisms, for example using standard Web Service testbed resource that needs to be exposed to the tester or user
Security mechanisms. by the gateway using techniques like packet forwarding,
B. Reference Point T2 application proxying, and/or network address translation.
Which kind of access and filtering is used depends on the
The Domain Manager implements an extensible layer that
service that should be made accessible and was set up using
allows the dynamic installation of specific Resource Adaptors.
Teagle. The task of the gateway at interface U2 is to ensure the
Each Resource Adaptor (RA) translates common instructions
availability of testbed resources in a secure manner without
into the specific protocols implemented by one or more
the loss of functionality.
testbed components. Therefore, the T2 interface is actually
implemented by each RA independently, as required by the E. Reference Point U3
peculiarities of the associated testbed components in order to Access from the customer’s machine or lab network to the
cope with the heterogeneity of the underlying testbed Virtual Customer Testbed (VCT) is granted by the gateway.
resources. Not all testbed components will need to support the This connection utilizes standard secure “dial in”
whole set of control, management, and test result retrieving technologies, such as Internet Protocol Security (IPSec), Point
functionalities supported by the Domain Manager. Each to Point Tunneling Protocol (PPTP), and Layer 2 Tunneling
Testbed component will have to implement the functionalities Protocol (L2TP). The gateway manages access limitations to
allowed by its nature and required by its intended. Standard the VCT associated resources that have been set up by the
management protocols (for example Simple Network customer using Teagle. The customer uses a standard Virtual
Management Protocol (SNMP)) will be supported and Private Network (VPN) client or VPN aware router to directly
provided by some default RAs. However, proprietary connect to a VPN concentrator (usually a gateway chosen by
interfaces will need to be supported by specifically developed Teagle) to become part of his VCT. Once interconnected, the
RAs. Since the presented architectural approach is generic in customer is able to address “rented” resources including
order to consider any possible underlying technology as configuration front-ends. Please note that at the moment the
testbed components (thus, providing flexibility to federate customer initiates an actual testing session, he becomes an end
heterogeneous testbeds), the specific technologies to be used user (therefore using ref. point U2) in our architectural
for the T2 interface are not fixed. The following general terminology. In this case he might or might not use a VPN
command types should be supported by the T2 Interface: client to connect to resources, as via U2, the natural resource
• Resource discovery interfaces can be accessed.
• Resource status
F. Reference Point I1
• Configuration
• Monitoring The interface defined by I1 provides a gateway-to-gateway
• Security connection, a data path between two testbeds. Communication
between the gateways uses the data plane only, there is no
• Quality assurance
control message exchange since the secure tunneling methods
• Collection of test results
are stateless and use pre-shared secrets. Routing between
• Tear down and de-provisioning
testbed components of different testbeds is done by the
gateway using intelligent routing protocols like Open Shortest
C. Reference Point U1
Path First (OSPF) and topology information, including VPN
This RP is the entry point for federation customers to setup parameters transmitted by Teagle through the Domain
interact with the federation control plane. It allows the Manager. Using the I1 interface, all gateways can form a
customer to access the Teagle tool in order to request meshed testbed interconnection network that is dynamically
operations related with four main aspects: created without exchange or stateful control
• Obtaining information on testbeds and associated
resources G. Reference Point I2
• Transparently customizing and managing a testbed The interconnection between a local gateway and the
environment internal testbed components is defined by the I2 RP. The main
• Accessing and managing test results purpose of this is to enable an isolated (e.g. by Virtual Local
• Obtain contact information for testbed and federation Area Network (VLAN) techniques) link layer access to all
responsible 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 points was given. The experience gained from implementing
components, the latter need to be directly connected to the our first prototype will guide the upcoming activities. In order
gateway or link layer by a switching device that honors link to allow for a more automated solution we need to find a way
layer isolation methods like IEEE 802.1q (VLAN). As long as to uniformly describe the involved domain resources. This will
the associated testbed component is assigned to a VCT, the be very challenging given the high heterogeneity of resources
associated gateway shall have exclusive link layer access for the system needs to deal with. Future efforts will therefore be
reliability and security reasons. centered around using a common and abstract way of
representing the resources on the federation control level. This
V. PROTOTYPE IMPLEMENTATION shall allow for domain specific languages and models to be
A first prototype implementation of the proposed used for different domains and to be mapped accordingly.
architecture has been realized and is currently being extended.
T1 has been implemented making use of the Service ACKNOWLEDGMENT
Provisioning Markup Language (SPML) and uses HTTP, Parts of this paper are based on work and ideas generated in
SOAP and XML to convey provisioning messages from the course of the project PII [17], which receives funding from
Teagle via a Domain Manager to a presence server and a XML the European Commission’s Seventh Framework Programme
Document Management Server (XDMS). The current (FP7).
implementation allows the remote setup, configuration, and
tear-down of the two server components. As part of a REFERENCES
demonstration scenario, two IMS domains (in Greece, [1] Chun, B. et al.: PlanetLab: an overlay testbed for broad-coverage
University of Patras and in Germany, Fraunhofer FOKUS) services. SIGCOMM Comput. Commun. Rev. 33, 3 (Jul. 2003), 3-12.
based on the Fraunhofer Open IMS Core [19] have been [2] B. White et al.: An integrated experimental environment for distributed
systems and networks. Proc. 5th Symp. on Operating Systems Design
interconnected using a VPN IPSec tunnel. IMS clients have and Impl. 255–270 (2002)
been registered at both domains but only one domain [3] Rao, N.S.V., Wing, W.R., Carter, S.M., Wu, Q.: Ultrascience net:
(Fraunhofer FOKUS) was controlled by a Domain Manager. network testbed for large-scale science applications. Communications
Using our first implementation of Teagle [20], the presence Magazine, IEEE, vol.43, no.11, pp. S12-S17, 2005
server and XDMS can be provisioned via the Domain [4] Florian Schreiner, Sebastian Wahle, Niklas Blum, and Thomas
Magedanz: Modular Exposure of Next Generation Network Services to
Manager. This allows the clients connected and registered in Enterprises and Testbed Federations. Second International Conference
both domains to make use of the functionalities offered by the on Communications and Electronics, HUT-ICCE 2008, pp 98 – 103,
two server components (group/contacts list via the XDMS and IEEE (2008)
[5] Future Internet Research & Experimentation (FIRE) Initiative website,
presence status of the contacts via the presence server) upon http://cordis.europa.eu/fp7/ict/fire/
request. T2 has been implemented mapping the T1 message [6] Gavras, A., Karila, A., Fdida, S., May, M., and Potts, M. 2007. Future
commands to XML Configuration Access Protocol (XCAP) internet research and experimentation: the FIRE initiative. SIGCOMM
messages, Session Initiation Protocol (SIP) messages, and Comput. Commun. Rev. 37, 3 (Jul. 2007), 89-92.
shell commands providing two simple RAs. In the current [7] OneLab project website, http://www.onelab.eu/
implementation, U1 allows the lookup of resources and simple [8] Federica project website, http://www.fp7-federica.eu/
provisioning. On U2 and U3 usual IMS communication [9] PlanetLab website, http://www.planet-lab.org/
[10] GÉANT2 website http://www.geant2.net/
messages (for example SIP and Real-Time Transport Protocol
[11] Global Environment for Network Innovations initiative website,
(RTP)) can be exchanged as defined by 3GPP using standard http://www.geni.net/
conformant IMS clients. The other architecture RPs have not [12] GENI Project Office, GENI System Overview, Document ID: GENI-
been the main target of our first implementation and will be SE-SY-SO-02.0, September 29, 2008,
realized in future versions of the architecture implementation. http://www.geni.net/docs/GENISysOvrvw092908.pdf
The scenario shows that the NDF (and the concrete testbed [13] Emulab project and testbed website, http://emulab.net/
use case) paves the way for new business models for testbed [14] GENI Project Office, GENI Spiral 1 Overview, Document ID: GENI-
FAC-PRO-S1-OV-1.12, September 29, 2008,
providers. For example, in our scenario, the Greek testbed was http://www.geni.net/docs/GENIS1Ovrvw092908.pdf
enhanced with additional functionality (offered by resources [15] GENI Project Office, GENI Control Framework Architecture, Document
that are physically located in the Fraunhofer FOKUS testbed ID: GENI-ARCH-CP-01.4, October 20, 2008,
http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkArch
in Berlin) using the NDF approach. This makes the Greek itecture/102008_GENI-ARCH-CP-01.4.pdf
testbed more attractive for local testing customers in Greece [16] TeleManagement Forum, NGOSS SID,
that are seeking to test application and client scenarios http://www.tmforum.org/TechnicalPrograms/NGOSSSID/1684/Home.ht
involving group/contacts lists and presence status. ml , 2008
[17] PII project website: http://panlab.net
VI. CONCLUSION AND OUTLOOK [18] Sebastian Wahle et al.: Technical Infrastructure for a Pan-European
Federation of Testbeds. In TRIDENTCOM 2009, Washington DC, USA,
The paper describes an architecture on how to federate April 2009. IEEE. Accepted for publication in 2009, ISBN: 978-1-4244-
2847-2, IEEE Catalog Number: CFP09364.
arbitrary network domains and their resources. Other related
[19] Open Source IMS Core website, http://www.openimscore.org
research activities in the field have been discussed before a
[20] Teagle website, http://www.fire-teagle.org
detailed insight into the proposed architecture and its reference
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.
Related docs
