|
As
computers went from rare to common, the field
of Computer Engineering was created to address
building systems. As computers go from common
to ubiquitous, connectivity and information
flow becomes the harder problem to solve.
Network engineers are needed to address the
problems of distributed systems and go beyond
just building bit pipes. The Internet is
having a strong impact on other technologies.
The simple approaches of the early
days have become increasingly more complex.
Accelerated services convergence calls for
professionals dedicated to this area.
Creating
laboratory exercises and adequate facilities
to supplement lecture is an important part
of creating an academic program in Network
Engineering. The goal of this proposal is
to support a Master’s program in Network
Engineering with facilities capable of demonstrating
ideas and concepts and allowing students
freedom to experiment.
Facilities
Concept
Using
the OSI Reference Model as a guide, Network
Engineering laboratory facilities should
be able to support exercises corresponding
to all seven layers (Table 1). Access is
usually required down to the hardware and
operating system level, so laboratory activities
must be placed in a sandbox, isolated
from the production network but with some
controlled access. The facility should be
able to support multiple courses and many
lab sections, so configuration must be flexible,
readily changed and readily reset back to
some known state. An additional goal is to
support, to the maximum extent possible,
distance learning. Whether video or web-based,
learning must be supplemented by lab exercises.
Everyone can’t have modern facilities at
their location. Making the lab remotely accessible
allows concentration of assets and the ability
to focus on keeping infrastructure up to
date. By designing for remote access, more
students may be served.
|
OSI
RM |
Lab
Facility |
Access |
Course
Coverage |
|
Application |
Network |
(TBD) |
(TBD) |
|
Presentation |
Services |
|
|
|
Session |
|
|
|
|
Transport |
Network |
|
|
|
Network |
Core |
|
|
|
Data/Link |
Embedded |
|
|
|
Physical |
Systems |
|
|
Table
1 – Facility Correspondence to OSI RM
These
requirements may be met by dividing lab facilities
into three areas:
- Embedded
Systems Facility – Addressing primarily
OSI RM layers 1 and 2, this facility
offers the most direct access to network
hardware, analyzers and performance monitors.
It includes VLAN capable switches, Intel-based
computers and allowances for multiple
media.
- Network
Core Facility – This equipment, composed
of dual-boot systems, routers, bridges,
and ATM switches, is aimed at OSI RM
layers 3 and 4. Here, students would
be allowed to configure/change operating
systems, routers, etc. Less emphasis
is placed on physical access while still
allowing direct control and recovery
from mistakes.
- Network
Services Facility – Systems forming this
area will support exercises primarily
at OSI RM layers 5-7. Students would
experiment with network servers (e.g.,
file; web; video), interprocess communication
and distributed systems.
Physically,
the three lab areas will be divided into
two rooms; however, remote access will be
abetted by the implementation of a Virtual
Network Lab. This facility will include systems,
proxy interfaces and controls to allow students
to access real communication equipment without
being physically present. It will provide
access to every OSI RM layer and support
distance learning. Actual equipment will
include parts of the other three areas, but
instrumented so physical presence is not
required. As time and experience allows,
all access and experiments would be done
remotely.
view
larger image
view
larger image
Virtual
Network Lab Characteristics
Actual
interface to the virtual laboratory facilities
is through a web browser such as Internet
Explorer or Netscape. Data are
submitted through HTTP POSTs and displayed
to the user as HTML. This choice allows the
maximum audience and also a clearly defined
path through organizational firewalls. [The
Mentor Labs implementation requires direct
TELNET access, rarely available to professionals
seeking access from inside their corporate
network.] The lab has an http server which
serves as a proxy for issuing commands and
retrieving responses. Once the proxy receives
that data from a user, it uses direct, out-of-band,
connections to the devices and systems within
the facility to issue commands. Whether the
proxy does any interpretation or modification
of the data determines the level of control
provided to the user.
Our
virtual laboratory is designed to offer a
broad spectrum of options for access control
management. One extreme is called voluntary
management (VM) in which the applications
and/or underlying experimental equipment
are directly accessible by the user, who
is given guidelines for proper use but not
prevented from actions inconsistent with
that guidance. On the other extreme, we have enforced
management (EM), where access to the
experimental equipment as well as individual
steps in the exercise are explicitly controlled
by the access control mechanism. In the following,
we briefly describe three techniques covering
the access management spectrum. Each has
its advantages and disadvantages for learning
and administration, as outlined below.
- Direct
Access – allows the user direct control
over the devices and programs assigned
to an experiment. This method allows
the most flexibility to the user and
least administrative overhead during
the experiment. However, it provides
the least assistance to the user and
lowers the likelihood of a successful
experience - problems are more likely
and user controlled recovery difficult.
In this situation, the vLab user interface
passes commands directly to the device(s)
being controlled. For example, in configuring
LANE and MPOA parameters on an ATM
switch, the student types commands
which are directly interpreted by the
switch. There is freedom to explore
many paths to a solution. However,
if the student enters an incorrect
NSAP (a twenty byte value), not only
will the resulting configuration not
work, but it’s likely the student will
lose communication with the switch
and be unable to complete any more
exercises. Because the state of the
system (e.g., the entered NSAP) is
not tracked by administrative means,
recovery is restricted to resetting
the devices to a baseline configuration.
- Filtered
Access – means user commands and device
responses are filtered through a proxy
program; direct control is not allowed.
This filter can allow guided learning
(e.g., correcting syntax or preventing
inappropriate commands). However, the
administrative overhead of creating
detailed filters is high. Filtered
service may also restrict opportunities
for innovation during an experiment,
when the administrator does not foresee
sufficient situations. Recovery from
problems may be easier as the system
can tell the current state. An exercise
may ask the student to change /etc/services on
a Linux server to add in an RPC service
and the filter could prevent editing
of other files. Or the filter could
track all the files touched by the
user up to some checkpoint; if the
user cannot proceed past the checkpoint,
only the changed files would need to
be rolled back for the student to try
again.
- Scripted
Access – provides for the least amount
of user control over an experiment.
Essentially all paths through an experiment
are predetermined and the user allowed
only choosing from a limited menu at
each step. Feedback on correctness
of choices is immediate and unrecoverable
failures can be avoided. On the other
hand, user innovation and exploration
is almost completely prevented. Rather
than allow the user to add an IP route
by command, the server could present
only the required options (e.g., network,
mask, metric, and gateway) and not
issue any command to the device unless
the parameters were in required ranges.
Extraneous responses (e.g., system
boot messages) from devices could be
suppressed rather than presented to
the user.
(a)
Direct Access
(b)
Filtered Access
(c)
Scripted Access
Figure
x: Three Access Control Methods
|
