Download Guidelines for ICETA 2007 Paper Preparation

ARCHITECTURE OF SEMI-VIRTUAL CAMPUS
FOR EDUCATION IN DISTRIBUTED DATA NETWORK LABORATORY
Petr Grygárek et al.
Department of Computer Science, Faculty of Electrical Engineering and Computer Science
Technical University of Ostrava, Tř. 17. listopadu, 708 33 Ostrava, Czech Republic
Tel.: (+420) 597 323 263, Fax: (+420) 597 323 099
E-mail: [email protected], http://www.cs.vsb.cz/grygarek
6th
Int. Conference on
Emerging e-learning
Technologies
and Applications
Abstract. The article presents architecture of semivirtual campus technical infrastructure for Edinet
project. Its aim is to integrate data network laboratories of multiple partners into single unified system
accessible by students remotely via Internet. The architecture is defined to integrate various existing
remotely accessible networking laboratories and education approaches. The intent was to reach
maximum flexibility to support efficient sharing of lab equipment including a possibility to create
temporary distributed lab topologies spanning multiple partners.
The High Tatras,
Keywords: collaborative learning, distance education, distributed learning, interactive learning,
Slovakia
September 11-13, 2008 network, infrastructure, virtual laboratory
The SVC architecture proposal was defined so that
necessary changes of existing partner labs were minimized.
It was necessary because of the fact that many partners
currently use their labs in real student education and the
process of migration to the common SVC has to be as easy
as possible. On the other hand, we wanted to develop a
consistent system with clear and well-defined architecture
which may be easily extended in the future, so the pure
encapsulation of existing solutions was not a wise option.
We also needed to minimize cost of new required hardware
and software licences so that free opensource technologies
were chosen for SVC implementation. This approach also
corresponds well with the academic nature of the whole
project.
1. INTRODUCTION
To improve efficiency of practical training in the field of
computer networking, it proved very useful to provide
remote access to networking laboratories. Because of high
cost of special laboratory equipment it also makes sense to
join effort of multiple educational institutions to share
equipment with other partners which allows individual
partners to specialize of particular special technology and
utilize lab equipment for other technologies owned by other
partners. The result of that cooperation is a virtual campus
which allows student to work with real network devices of
any partner, so we call it “semivirtual” to emphasize the fact
that students get real practical experience which cannot be
reached using of any kind of device simulators.
During design phase of the overall SVC architecture we
took into account many years of our experience with
development of
remote access lab solutions [1],[2],
distributed virtual laboratory architectures [4] and real
operation of both nondistributed [3] and distributed [5]
semi-virtual education environment. Because the time to
implement SVC and prepare the whole distributed
environment for piloting was only a couple of months, we
decided to defer utilization of advanced features fieldproven in our Distributed Virtlab [5] to the later stages. Our
experience with piloting Distributed Virtlab revealed that
handling of such features as dynamic creation of distributed
virtual topologies with dynamic search of lab devices
suitable for particular reservation is rather demanding to
organize even in scope of Northern Moravia Distributed
Virtlab installation. It would be very risky to try to
implement it in such short time in a large-extent SVC
covering multiple very distant universities.
Because of advantages of participation in such semivirtual
campus (SVC) environment, we joined the European Union
project called “Education in Distributed Data Network
Laboratory” (EdiNet) operated under EU Lifelong Learning
Programme. Our responsibility in scope of Edinet project is
the architecture design and implementation of semivirtual
campus technical infrastructure. In the following article, we
want to share our experience with definition of a such
architecture. Our results seem to be general enough to suit
rather diverse needs of individual partners and all potential
usage patterns and pedagogical approaches which are
planned to be tested in the implemented semivirtual campus.
The first step of the architecture definition was the thorough
investigation of existing partners' remote access solutions,
which were rather diverse. Although almost all partners took
one of the two possible approaches (i.e. VPN-based
approach or solution with exposed terminal server),
individual solutions varied considerably in the level of
reservation system implementation and overall flexibility of
the remote laboratory usage.
On the other hand, our goal was to develop an architecture
that will be flexible and adaptable enough to allow mutual
sharing of partners' lab equipment as effectively as possible.
Our politics is that all partners will have equal access to
resources of other partners, including both lab devices and
1
lab manuals or other educational documents. There was also
a requirement to support statically preconfigured distributed
virtual topologies spanning multiple partner's labs.
database and database of user groups (see later). Local AAA
servers authenticate users of respective partner and maintain
local user databases. VPN Gateways provide remote access
to Lab Management Network of individual partners’ labs, as
will be described in the next section.
The main parts of the architecture that had to be designed
were common remote access system, reservation system
which reasonably organizes tasks and lab pods and common
authentication and authorization (AAA) infrastructure. The
general philosophy of all of the mentioned parts will be
described in the following sections.
3. THE INTEGRATED REMOTE ACCESS
SOLUTION
The remote access solution is designated with primary intent
to support all kinds of management interfaces of lab network
devices used up to now by partners or considered in the
future. Currently, we need access to lab networking devices'
RS232 consoles and Telnet/SSH/Remote Desktop access to
manage lab PCs. In the future, it is expected that a lot of
networking devices will be manageable primarily using Web
interface. There is also lot of manufacturers who implement
their own L2/L3 management protocol and proprietary
(commonly Windows-based) management applications. We
plan to manage such devices from lab PCs with
appropriately configured Web browser and all necessary
proprietary management applications preinstalled.
2. COMPONENTS OF THE ARCHITECTURE
The SVC distributed architecture is composed of Common
Portal, Local AAA Servers and VPN Gateways to Lab
Management Networks of individual partners’ labs, as
shown of figure 1.
To integrate access to RS232 consoles with both text-based
and GUI-based access to lab PCs into one technical
solution, we have chosen to implement an VPN-based
access for remote management of lab equipment (see Figure
2). Lab PCs will have one NIC card connected to the Lab
Network and another one connected to so called Lab
Management Network. Lab Network contains lab devices
used by students to solve tasks, while Lab Management
Network is used to access management interfaces of lab PCs
and Terminal Servers, which makes RS232 consoles of lab
networking devices available to the remote user using
reverse Telnet. Various kinds of terminal servers may be
utilized (either commercial or partner's own hardware
prototype).
Figure 1: Overall Architecture of the SVC
The Common Portal acts as the main SVC WWW portal. It
hosts databases of tasks and lab devices, reservation
Figure 2: Basic remote access architecture
2
To allow integration of remote desktop clients into remote
user’s GUI, it is desirable do unify methods of lab PC
access over all partners. At the time of writing of this article,
TightVNC [8] was chosen as the most suitable open,
bandwidth-efficient and cross-platform solution.
3.1 Lab Interconnection
In some situations, partners may want to interconnect lab
devices from multiple labs into distributed virtual topology
and provide the resulting (even preconfigured) lab pod for
remote access for a limited period of time. The technical
solution how it will be implemented is depicted on Figure 3.
Both Lab Networks and Lab Management Networks of
partners' labs involved in distributed virtual topology have
to be virtually connected together.
In the real lab implementations we do not really expect wide
usage of "real" lab PCs. To simplify and automatize lab
management, reduce cost, power consumption and required
space, we expect that partners will want to use some sort of
virtualization technology to simulate multiple lab PCs using
single server. It will also simplify resetting of PC
configurations/filesystems to the known state at the
beginning of every reserved timeslot.
For location-independent access to management interfaces
of lab devices spread across labs of multiple partners, Lab
Management Networks of all partners will be connected
together with VPN tunnels (green dashed line on Figure 3).
In the first piloting environment we plan to implement full
mesh of tunnels among partners and utilize static routing. If
more partners join our environment later, topology may be
optimized and suitable dynamic routing protocol
implemented.
As can be seen from Figure 2, remote user's PC is used only
for management of lab equipment, including lab PCs. It is
never incorporated directly to the Lab Network. To manage
lab network devices by mean other than RS232 console, the
user first accesses some lab PC and then uses software
preinstalled on that PC to manage lab network devices.
Because the configuration of lab PCs' operating system,
WWW browser and other software is completely known to
and under control of local lab administrator, we do not have
to solve problems with poorly installed or malicious
software on remote user's PC as we would have in case if we
would have been used remote user's PC as a part of the Lab
Network.
By interconnection of Lab Management Networks, the
distributed nature of the virtual topology becomes
completely transparent to the user. Controls of Web pages
providing access to lab devices' management interfaces may
just operate with IP addresses of management interfaces of
lab PCs and terminal serves regardless of in which partner's
laboratory they are actually located.
Every lab is equipped with Linux-based VPN gateway
connected both to the local Lab Management Network and
to the Internet. It allows remote (VPN) access to the Lab
Management Network. After successful authentication,
Tunnels between Lab Networks of partners participating in
particular distributed virtual topology (yellow dashed line(s)
on Figure 3) will be preconfigured manually when needed.
Figure 3: Interconnection of multiple partner's labs
authorization and creation of VPN tunnel, remote user's PC
becomes virtually part of respective Lab Management
Network. An access list (ACL) will be dynamically applied
on the VPN gateway to allow remote user to access only
management interfaces of those lab devices which the user
previously reserved for a current timeslot. The access is
authenticated using one-time passwords generated by
Common Portal. Those passwords are passed to remote
clients which launch OpenVPN [9] client transparently via
HTTPS. Details can be found at [6].
We plan to use OpenVPN [9] SSL VPN because we need to
be able to create multiple parallel virtual links between a
pair of Topology VPN gateways in many distributed virtual
topologies. SSL VPN allows to differentiate them using
TCP/UDP ports. To ensure OSI layer 3 protocol
independence and to allow layer 2 control protocols to pass
through virtual links, virtual topology tunnels will be
implemented as Layer 2 tunnels. More detailed example of
implementing distributed virtual topology in the described
way may be found in [8].
3
4. RESERVATION SYSTEM
Our general goal during design of the reservation system
was to develop a system which allows to share lab
equipment in dynamically changing environment and with
reasonable level of flexibility. To optimize usage of the
whole SVC and thus gain maximum pedagogical effect, we
stated the following requirements for the organization of the
SVC:
 There must be a possibility to offer lab pods to
solve tasks which require various network
topologies.
 For some tasks, lab devices have to be
preconfigured as required for that particular task.
 There must be a method to offer multiple
alternative lab pods suitable to solve particular task
in parallel (either by the same or by multiple
partners' labs) .
 It is ineffective to dedicate every lab pod for
solution of only single fixed task.
 Lab admins will want to change lab pod topologies
over time.
Our reservation system is based on the global system
noticeboard. Lab administrators advertise lab pods with
various topologies and device preconfiguations as available
for some time period on the global noticeboard maintained
at Common Portal. The description of every task specifies
requirements of lab pod on which it can be solved. These
requirements include specification of lab devices which may
be utilized, device interconnection topology and eventually
required preconfiguration of individual devices. When
student selects a task to reserve, Common Portal offers
him/her those lab pods which can be used to solve required
task and times when they are available. The student then
reserve a timeslot on particular lab pod. There are no fixed
timeslots, students may reserve any timeslot which fits into
period during which particular preconfigured lab pod is
available, according to the advertisement on the
Noticeboard.
Using that paradigm, we were able to reach complete
decoupling of tasks from preconfigured lab pods and
increase flexibility of lab pods usage considerably. Every
task just specifies (using so called Preconfiguration
Description) requirements for the lab pod suitable to solve
the task. At the same time, lab administrators advertise their
Preconfiguation
Implementations
(i.e.
lab
pods
preconfigured according to some
Preconfiguration
Description) on the global noticeboard. It allows various
alternative tasks (with the same topology and
preconfiguration requirements) to be solved on the same lab
pod. The whole philosophy of is depicted at Figure 4.
Figure 4: Reservation system philosophy
User may create user groups by themselves by listing other
users, potentially from multiple partner sites. The creator of
the group becomes its owner and may modify or delete it.
Group owner may make reservation for his group and all
members of the group may equally access the reserved task
during the reserved timeslot. Teacher may reserve additional
time for checking of students’ configurations after the end of
the timeslot. Every user may also reserve timeslot
exclusively for himself/herself, because separate group is
automatically created for every single user. Individual
remote work is thus handled as a special case of more
general group-based reservation paradigm.
Reservations are maintained in Reservation Database on the
Common Portal.
5. AAA INFRASTRUCTURE
To simplify user administration process, we decided to
avoid any central authority which manages all user accounts.
Instead of that, every partner maintains it's own user
database which is accessible to the rest of SVC via Local
AAA Server.
Using that concept, every partner is
responsible for management of his own user accounts. The
another advantage is that partners may easily integrate
Edinet user databases with existing local user databases and
authentication mechanisms, like institution's LDAP or
RADIUS servers. Lab admins may also easily perform
offline imports of users accounts exported from institutional
information systems directly to the Edinet local user
database by themselves.
With regard to various and potentially very different
planned usages of the SVC (individual remote work,
teacher-controlled work of student's group from the
classroom and others), we decided to take group-based
reservation approach. It means that timeslots are reserved
for groups of users, not for users as individuals.
Although we assessed usage of PKI and user certificates
first, we finally decided to use username/password approach
4
to authenticate users to eliminate overhead of handling
certificates on both user and SVC side. Working with user
certificates would be very difficult on shared classroom
computers because of limited students' operating system
privileges and potential risk of stealing of student's
certificate. Another advantage is that users may even use the
same passwords as they use in their home institution for
other purposes.
7. CONCLUSIONS
The SVC architecture presented in the article is now being
implemented by Edinet SVC development team of VSB-TU
Ostrava. It will be ready during summer 2008 and after
period of internal testing and adaptation of partners' labs it
will be released for piloting in real distributed teaching
environment starting at October 2008. The outcomes of the
piloting phase will be published.
Users are assigned names in the username@realm format,
so usernames are scoped. Users are authenticated in their
"home" institutions (implied by realm part of their
username) by Local AAA Servers. Together with result of
the authentication (true/false), the local AAA server will
also return a set of user's attributes (name-value pairs) from
local user database.
8. REFERENCES
[1] Grygárek, P., Seidl, D., Němec P.: Virtual Network
Laboratory for CNAP. Annual Conference of Cisco
Networking Academy Program, Brno 2005. Available at
http://www.cs.vsb.cz/vl-wiki/images/a/ad/Virtlabprezentace-CNAP-Brno.pdf. [April 2007]. [In Czech]
As soon as the user is authenticated, it is allowed to log in to
the Common Portal. His/her authorization to perform
particular operations is based on the user's roles stored in
user database and provided as user attributes by local AAA
servers. Shibboleth [10] was chosen as global AAA
middleware.
[2] Grygárek, P., Seidl, D., Němec, P.: Enabling Access to
Equipment of Computer Network Laboratory for
Practical Trainging via the Internet. Proceedings of
Technologies for E-Learning conference, FEL ČVUT
Praha, 2005, ISBN 80-01-03274-4, pp. 43-52. [In Czech]
6. SUPPORTING LAB MAINTENANCE SYSTEMS
[3] Grygárek, P., Practical Experience with Implementiation
of Virtual Computer Network Laboratory and Proposed
Ways of its Further Development. Proceedings of
Technologies for E-Learning conference, FEL ČVUT
Praha, 2006, ISBN 80-01-03512-3, pp.58-68. [In Czech]
To allow SVC to be operated without constant
administrators' interaction, it is necessary to be able to
return configurations of lab devices into original
preconfigurations
before
each
reserved
timeslot
automatically. Because of the diversity of utilized lab
devices, their configuration interfaces and ways of resetting
them to factory defaults, it is not possible to develop a
system which will solve this task in genereal. For that
reason, we decided to define a SVC component named
Configuration Clearing Server, which will be implemented
by each partner by himself and will provide unified
software interface to the rest of SVC to request reset of
individual local lab devices. The real implementation of the
cleaning method is left to local administrators. Currently, we
expect usage of various power switches to simply power
networking device off and on and a system of Shell scripts
to reload instances of simulated PCs. We foresee that this
mechansm will have to be accompanied by another security
measures, such as disallowing users to store configurations
into lab devices’ FLASH, as we do in Virtlab [2].
[4] Grygárek, P., Milata, M., Vavříček, J.: The Fully
Distributed Architecture of Virtual Network Laboratory.
Proceedings of ICETA, Stara Lesna, High Tatras,
Slovakia, 2007, ISBN 978-80-8086-061-5
[5] Grygárek,P., Milata, M.: Piloting Environment of
Distributed Virtual Networking Laboratory. Proceedings
of Virtual University, Bratislava, Slovakia, 2007, ISBN
978-80-89316-09-0, pp. 209-212.
[6] Edinet SVC Technical Infrastructure Architecture
Design/Remote Access and Lab Interconnection [online],
2005, [cite 2008-04-13], Available at WWW:
<http://edinet.cs.vsb.cz/index.php/Remote_Access_and_
Lab_Interconnection>.
[7] Edinet Lab Interconnection Implementation Example
[online], 2008, [cite 2008-04-13], Available at WWW:
<http://edinet.cs.vsb.cz/index.php/Remote_Access_and_
Lab_Interconnection#Lab_Interconnection_Implementati
on_Example>.
Power switch may also be optionally made available to
students who solve particular task. From students' point of
view, switching power of individual lab devices is
accomplished using controls of WWW page which makes
management interfaces of individual lab devices available to
him/her. Since we need to limit user to control power of
only those devices that are reserved by him/her during the
current timeslot
and handle power switches of all
manufacturers uniformly, we created a software component
called Power Switch Controller which acts as a proxy
between user and any kind of real power switch.
[8] TightVNC: VNC-Based Free Remote Control Solution
[online], 2007, [cite 2008-04-13], Available at WWW:
<http://www.tightvnc.com/>.
[9] OpenVPN - The Open Source VPN [online], 2008, [cite
2008-04-13],
Available
at
WWW:
<http://openvpn.net/index.php>.
[10] Shibboleth Project - Internet2 Middleware [online],
2008, [cite 2008-04-13], Available at WWW:
<http://shibboleth.internet2.edu/>.
5
THE AUTHOR(S)
Petr Grygárek (Ph.D, Msc.) is a professorassistant at Department of Computer
Science at VŠB-TU Ostrava. His
professional interest is focused on computer
networking, distributed systems and
computer hardware. He has a couple of
years of experience with development of
virtual networking laboratory architectures and is a main
responsible for semivirtual campus design and its
implementation in scope of Edinet project. He is also a
coordinator and instructor (CCNP,NS,CCNA) of Regional
Cisco Networking Academy at VSB-TU Ostrava.
The ideas presented in the
article were developed
jointly by Edinet WP3 SVC
Development Team under
supervision
of
Petr
Grygárek. Persons who
contributed most to the
architecture definition were Ivan Doležal, Jiří Grygárek,
Adam Janošek, Tomáš Kučera, Marek Malysz and Martin
Milata (in alphabetical order). All of them are empleyees or
students of VŠB-TU Ostrava.
ACKNOWLEDGEMENT
This work presented here is supported by
EU Lifelong Learning Programme project “E-learning in
Distributed Data Network Laboratory (EdiNet)”.
6