ENVIRONMENTAL ACQUISITION IN MOBILE NETWORK

SIMULATION

David Buchmann, Dominik Jungo, Ulrich Ultes-Nitsche

telecommunications, networks & security Research Group

Departement of Computer Science, University of Fribourg

Boulevard de P

erolles 90, 1700 Fribourg, Switzerland

Keywords:

Environmental Acquisition, Wireless Network Simulation, Validation by Simulation, Network Conﬁguration

Management.

Abstract:

The type or class of an object is not always sufﬁcient to decide on its runtime behaviour. In many cases, the

context of the object is also important. Environmental acquisition is a concept to handle context in information

models.

We explore the use of environmental acquisition for the management of computer network conﬁguration and

for network simulation. Physical location or subnet membership are part of the environment for a computer

in a network. For the simulation of networks, environmental acquisition will be especially useful to model

mobile devices moving from one area into an other.

The concept is illustrated using the network conﬁguration management project Verinec.

1 INTRODUCTION

Class inheritance is an important concept for clean

design, avoiding redundant deﬁnition. It is not only

used in object oriented programming languages, but

in other ﬁelds too. In network conﬁguration, we can

say a node is of a certain type. It might be a work-

station or ﬁrewall appliance. There can be specialisa-

tions for distinct requirements on hard- and software,

like a graphics workstation or a web developer work-

station.

However, the “is a” hierarchy is not sufﬁcient for

all kind of information model. Many objects also have

a “is in” hierarchy, that is, their context is relevant

for their behaviour. Taking the context into account

can improve network conﬁguration management to

a great extent. Networked devices are located in a

room, appear in the subnet they are connected to and

so on. The contexts deﬁne which printer to use by

default, the network gateway and many other conﬁg-

uration items.

Under the term environmental acquisition, (Gil and

Lorenz, 1996) present a concept to handle context.

The idea of acquiring information from the contain-

ment hierarchy has been implicitly used in many

places. Gil and Lorenz propose to explicitly model

acquisition in the description language. In this paper,

we will discuss the implications of environmental ac-

quisition for modelling network conﬁguration and for

simulating networks containing mobile devices. The

discussion is illustrated with examples how acquisi-

tion is used in the network conﬁguration management

system Verinec

In the following subsection, we will brieﬂy intro-

duce the Verinec project and look at related work in

the area of network management. Section 2 explains

the concept of environmental acquisition in general.

We apply the use of acquisition for network conﬁg-

uration management in Section 3. In Section 4, we

explore the application of acquisition to network sim-

ulation in the context of simulating mobile devices

operations. Finally, Section 5 holds the conclusions

and presents some ideas for future research on the use

of environmental acquisition in the context of network

management and simulation.

1.1 The Verinec Project

With the Verinec project, we aim to outline a tool for

designing and conﬁguring heterogeneous networks.

The Veriﬁed Network Conﬁguration (Verinec) project

is supported by the Swiss National Science Foundation

under the grants number 200021-100645/1 and 200020-

108056/1.

108

Buchmann D., Jungo D. and Ultes-Nitsche U. (2006).

ENVIRONMENTAL ACQUISITION IN MOBILE NETWORK SIMULATION.

In Proceedings of the International Conference on Wireless Information Networks and Systems, pages 108-113

 SciTePress

We try to bridge the gap between network discovery,

network design and validation and network conﬁgu-

ration automation. The core of Verinec is a central

network deﬁnition in an XML language independent

of speciﬁc products. The language deﬁnes speciﬁc

expressions to conﬁgure each service, allowing the

application to actually understand the semantics of

the conﬁguration data. This approach is less ﬂexi-

ble when it comes to integrating new services. In-

tegration would be easier when operating on imple-

mentation speciﬁc conﬁguration ﬁles. What we gain,

however, is the possibility to validate the correct se-

mantics of the conﬁguration. Additionally, we get the

freedom of exchanging one implementation of a ser-

vice for another without having to change the internal

conﬁguration representation.

The network is deﬁned in a hierarchical way. On

the lowest level of networks, we specify which net-

work interfaces are connected physically. For an in-

terface, we can really say that it is in a network. This

allows to properly model nodes having more than one

interface as belonging to several subnets. To aug-

ment semantic information, physical networks can

be grouped into logical networks to model both ge-

ographical areas (ofﬁce, ﬂoor, building) and logical

groups (broadcast domains, subnets). These groups

will come in handy later on, when we discuss how to

avoid conﬁguration redundancy.

Distribute

Create

Verify

Real Network

Definition

Network

Figure 1: Verinec Workﬂow: Deﬁne network from existing

network and user input – Validate correctness and ﬁx mis-

takes – Distribute conﬁguration.

Several modules written in Java are built around the

network speciﬁcation. Figure 1 depicts the complete

workﬂow of the Verinec system.

There is a module to create and modify the XML.

It has a network scanner built into it to automatically

discover the layout of existing networks. Conﬁgura-

tion importers can read conﬁguration ﬁles of services.

A graphical editor allows to correct and update the

network conﬁguration.

Having a central administration tool is convenient

for administrators as they do not need to switch be-

tween tools speciﬁc to each device and it helps keep-

ing track of the complete network inventory. More

important in our context, the central conﬁguration is

a basic requirement for automated correctness test-

ing. Once the conﬁguration is established, we can

run sanity checks on the single nodes and validate

the correctness of the conﬁguration using the valida-

tion module. Using simulation, we can ensure that

a given conﬁguration will not disturb network opera-

tions prior to deploying it. The validation module runs

test cases to validate the network similar to unit test-

ing in software development (Jungo et al., 2005). The

simulation approach allows to ﬁnd out much more

than would be possible by static examination of the

conﬁguration or even by running tests on a real net-

work. For example, we can simulate the breakdown

of any device to test fail-safeness.

Having validated a conﬁguration in a design tool

does not prevent the administrator from making mis-

takes if he has to apply it manually to the devices.

Thus, Verinec provides for automated conﬁguration

deployment to avoid introducing errors while porting

the validated conﬁguration to the actual network. The

adaption module (Buchmann et al., 2005) translates

conﬁguration data from the XML document into a for-

mat suitable for distribution on the target device and

deploys it using existing protocols for remote conﬁg-

uration.

1.2 Existing Work

There exist tools to speciﬁcally administer large

groups of routers, e.g. by CISCO or IPAT

. Splat

(Abrahamson et al., 2003) specialises on managing

just the edge devices. Such tools are mostly used by

service providers. Enterprise or university networks

are a lot more heterogeneous than a service providers’

infrastructure. Besides switches and routers for the

internal network and external connections, one ﬁnds

different servers and ﬁnally workstations that need to

be conﬁgured. Verinec addresses these issues by pro-

viding a framework to add new services to conﬁgure

when needed.

Several projects exist for administrating the com-

puters in university networks. Cfengine, the “Con-

ﬁguration Engine” (Burgess, 1995), provides a high

level scripting language and focusses on ﬁle manip-

ulation on Unix systems. The “Local ConFiGuration

system” (Anderson and Scobie, 2002) has a focus on

installing software on Unix hosts. Both need an agent

running on each node, contrary to Verinec. They use

a less semantically rich deﬁnition language for the

network than Verinec does. Netopeer (Lhotka and

Novotny, 2005) uses a conﬁguration language simi-

lar to Verinec and also uses the approach of having

plugins to remotely conﬁgure the actual devices. The

project is developed in the context of an IPv6 project

and thus focussed on routing, while Verinec aims at

conﬁguring all network services.

www.wandl.com/html/ipat/IPAT_new.cfm

The conﬁguration language “Anomaly” (Logan

et al., 2002) was developed to explore the possibil-

ities of environmental acquisition for network man-

agement. It is a simple conﬁguration language to

deﬁne properties and use them in the style of logic

programming. The language is less ﬂexible to ex-

tend for new services than the Verinec XML deﬁni-

tion. Anomaly seems to be targeted at Unix hosts

only, while a central concept for the Verinec project

is device independence. Work on the anomaly project

seems to have ceased.

2 ENVIRONMENTAL

ACQUISITION

Environmental acquisition is the process of acquiring

information from the current container of an object.

The concept has ﬁrst been presented under this name

in (Gil and Lorenz, 1996). We will use it in the con-

text of network conﬁguration and simulation, but the

concept can be applied to all domains having objects

and containment hierarchies.

Object oriented systems use the notion of “class”

to form hierarchies of types. A subclass is a kind of

its superclass. It thus has to inherit all features from

the superclass, possibly extending them. The features

are all known before the classes are instantiated and

do not change during execution. Instances of classes

have the features of their class and superclasses.

The type hierarchy is however not the only impor-

tant relation an object can have. Some features de-

pend on the containment structure. Let us look at an

example. When designing a mobile phone, the man-

ufacturer might offer differently coloured variants of

the same model. The device consists of electronics,

a display and a case. Display and insides will not

change just because we want the colour to be differ-

ent. It is the outside which is interesting here. The

casing can be further divided into front side, backside

and the keys.

The schematic containment hierarchy is shown in

Figure 2. The parts of the casing will have a com-

mon base class, telling the material to use and similar

information. For one variant of the device, the keys

should have the same colour as the casing front. If

we would use inheritance to ensure this, we would

have to pretend that each key is a kind of casing front.

Clearly, considering the front as a container for the

keys and letting the keys acquire their colour from the

container is more natural.

Acquisition allows for environmental polymor-

phism. Objects of the same class can show differ-

ent variants of behaviour depending on their environ-

ment. This is not to be confused with subtype poly-

morphism, where code written to operate with a class

Casing

− Colour

Front Back

− Colour − Colour

Mobile Phone

Electronics

−Colour

Keys...

Figure 2: Containment hierarchy of a mobile phone.

is also able to handle all of its subtypes. Here, the

code is parametrised by the actual object it operates

on, while with environmental acquisition, an object is

parametrised by its container.

In opposition to subclassing, a contained object

should not acquire all features from its container. For

a proper design, (Giland Lorenz, 1996) propose to ex-

plicitly list the features to acquire from the container.

To avoid long lists of features, it is possible to form

logical groups and simply declare the whole group to

be acquired. In the mobile phone example, this could

mean that the keys acquire material surface properties

like colour or roughness from the body. The shape of

the part or information about the quantity of raw ma-

terials needed to build that part on the other hand are

typical type information which should not be acquired

but inherited.

3 ACQUISITION IN NETWORK

CONFIGURATION

In large networks, many devices fulﬁl similar tasks.

Redundancy in conﬁguration data is a problem for

network setup, as there is a considerable risk of for-

getting to update mistakes in every occurrence. In

larger settings, it is practically impossible to admin-

istrate all aspects of each device manually.

Templates are used to encapsulate common settings

of different device types. Typically, we would use dif-

ferent templates for client machines, network routers,

server machines and so on. This is a class hierarchy,

each node is a certain type of machine.

However, there is information not deﬁned by the

type but by the environment of the node. For nodes in

the same subnet, many features will be or even must

be the same. The most obvious is the subnet mask,

also having an impact on valid static IP addresses. On

the services level, think of the ﬁle server a client has to

use or the name of the default printer. It is of course

possible to duplicate this information in every node

conﬁguration, but when something changes, the ad-

ministrator has to update every occurrence of the set-

ting. This is not just a waste of time but also a severe

threat to the reliability of a network. It is just too easy

to forget to correct every occurrence of redundant in-

formation.

We could start to create special subtypes (tem-

plates) for each subnetwork. However, this is not a

clean design and its limits show when we have nodes

of fundamentally different types in the same subnet. If

a workgroup server and client machines share a com-

mon subnet, they need to use the same gateway for

accessing the rest of the network. But this does not

make them be of the same type. One approach could

be to use multiple inheritance, allowing a node to be

of type “client” and of type “in-subnet A”. However,

being in a subnet is a typical containment hierarchy

and is not well represented by a is a relationship.

This is where environmental acquisition comes in.

The hierarchical network structure, as we have it

available in the Verinec project, can be used to de-

ﬁne common properties for all nodes within an area.

From physical location in an ofﬁce, it is for example

possible to choose the correct default printer and from

the subnet of a node deﬁnes network mask and default

gateway.

Variable declarations are used to represent and ref-

erence context information. Instead of a concrete

value, the node conﬁguration can reference a vari-

able. Even more interesting, the default conﬁguration

attributed to the type deﬁnition can also use the vari-

ables. The variables are evaluated in the context of

the nodes of that type. A node might be completely

conﬁgured by specifying its name, its type to choose

the right conﬁguration template and the context it is

in.

The nodes in Verinec are considered as composites

of hardware and the services they offer. It is actually

the individual services which need to get properties

from the network. The interfaces are bound to exactly

one network and can acquire information from it. For

the services of a node, we need to specify precedence

to choose from which interface’s environment to get

information ﬁrst.

3.1 An Example Network

Figure 3 shows the different relations of nodes with

their context and with their classes. The machines

diufpc01 and diufpc02 are of type client, which

deﬁnes many properties like routing setup or user ac-

Server Client Router

default_printer

default_gw

netmask

Office 404:

Figure 3: Network conﬁguration with environmental acqui-

sition.

counts. However, the information about the default

gateway, default printer and the netmask are taken

from the network of ofﬁce 404, their environment.

The server diuf-serv is of a completely different

type, but gets gateway, printer and netmask from the

same environment. The d-gateway ﬁnally is not

completely in the ofﬁce 404 network. Its inbound in-

terface still acquires the netmask, but the rest is to be

treated differently. The deﬁnition of interface prece-

dence for acquisition is important here, otherwise the

gateway might get assigned the default gateway of the

ofﬁce 404 network, which it is itself.

The gateway is a good example, why acquisition

should never occur implicit, but be declared explicitly.

Assume the acquisition would happen automatically.

The gateway would get the conﬁguration for a default

printer, which is nonsense. At the same time, the

printer would be assigned a default gateway, which

is not applicable neither.

If Verinec is to manage a DHCP server, it should

conﬁgure it to tell the DNS server the IP’s as it assigns

them to clients. As long as all DHCP addresses are

assigned using a ﬁxed mapping (i.e. based on MAC

addresses), DHCP and DNS servers could also share

a common table.

Addresses conﬁgured statically on the interfaces

provide an interesting case for the DNS server. It is

redundant to deﬁne the name to IP mappings within

the DNS server again. However, the DNS server is

not contained in each of the nodes, but would need to

acquire the mapping from the nodes. In this situation,

the object needs information from its surrounding ob-

jects.

To resolve this situation, variable values can be

more than simple strings, but full XML structures.

And the variable reference can specify an XPath

choose only a part of a value. With this solution, the

environment can deﬁne a list of mappings between

host names and their static IP’s. The DNS server can

use the complete list for his database, and every node

can select its own IP from the list using XPath.

Validating the conﬁguration (for example using the

Verinec simulator) is only a last resort to detect errors

before the conﬁguration is applied. Avoiding the mis-

takes being introduced into the conﬁguration in the

ﬁrst place is even better. Environmental acquisition

helps towards this goal by avoiding redundant infor-

mation and thus the potential for conﬂicting settings.

There are still circumstances where we need valida-

tion though, which we will discuss in the next section.

4 SIMULATING MOBILE

NETWORKS

Simulation takes the central role in testing the valid-

ity of the conﬁgurations within Verinec. In this sec-

tion we will introduce the basic idea of validation by

simulation and discuss the impact of environmental

acquisition on the simulation. Our network simula-

tor (Jungo et al., 2004) is is based on the event based

simulation framework DesmoJ (Page et al., 2000).

The simulator reads the network conﬁguration and an

XML document deﬁning a list of input events that

need to be scheduled, for example the launch of an

application or sending an IP packet.

The output of the simulator is an event log in the

same format as the input document. Each XML el-

ement of the input document is copied to the output

and the events caused by it are represented by child

elements. For example, launching a ping command

produces a series of events like MAC resolution or

sending and receiving of IP packets. All those events

are grouped under the “ping” input event.

The log ﬁle produced by the simulator represents

the network’s behaviour under the given user interac-

tion (input events). It can be checked against a se-

ries of semantical test (Jungo et al., 2005) written in

clixml (Jungo et al., 2006). These tests are similar

to unit tests for programming languages and should

be satisﬁed before the conﬁguration is deployed to

the network. The log ﬁle is enriched with meta data

referencing to conﬁguration elements involved in the

behaviour that produced an event. If a semantical test

fails, the meta data helps to ﬁnd the conﬁguration part,

which made a test fail. After successful tests, the con-

ﬁguration should work as desired and be free of prob-

lematic conﬁguration elements.

XML Path Language is a compact syntax for address-

ing portions of an XML document.

4.1 Acquisition in the Simulation

Environmental acquisition can not only be used for

deﬁning redundancy free node conﬁguration, but also

to simulate and test the conﬁguration of a node in

a dynamic environment. Introducing the concept of

mobility yields the difﬁculty that the environment

changes during the simulation.

Let us look more closely at the case of a mobile

device with Wireless LAN (WLan) capabilities. The

device can change its position within the network and

thus move into range or out of range of base stations.

For static wired networks, the network deﬁnition tells

the simulator at startup on which interfaces a packet

sent over a cable will arrive. Unlike wired networks,

the wireless environment can only determine at run-

time which packets will be received by which nodes.

The mobile device needs to be in range of a base sta-

tion to be able to communicate. When a device or

base station sends a packet, the simulation framework

needs to know which devices are in range, to decide

where to schedule the packet’s reception.

Wireless network client drivers often allow to be

conﬁgured to connect automatically to a network.

Different aspects like encryption and signal quality

can be taken into account. But since our model does

not know signal quality, automatic reconnection is not

possible to simulate. We ignored signal quality for

several seasons: For the Verinec project, we are inter-

ested in deciding whether the conﬁguration is seman-

tically correct. Signal quality is quite hard to predict,

and simulating it would make the framework much

more complicated. We thus simplify the concept by

deﬁning events which explicitly tell the simulator that

a device gets into or out of range of a base station and

when it initiates a connection to a network. We de-

ﬁned the events get in range of, get out of range of,

connect and disconnect. Connect will tell the higher

level services to simulate DHCP or similar protocols

to establish a connection with the new network, and

requires being in range of the speciﬁed base station.

The listing in Figure 4 shows an extract from an event

input ﬁle where ﬁrst the mobile device loses connec-

tion to the base station “hall”, gets into range of the

base station “room” and connects to it.

<wlan-range type="out" base-station="hall" />

</event>

<wlan-range type="in" base-station="room" />

</event>

<wlan-connect base-station="room" />

</event>

Figure 4: Input events to change the environment.

From the device’s point of view, changing its posi-

tion means getting into a new environment. For the

other devices, like mobile devices in an ad hoc net-

work or the base station in an infrastructure mode

network, the mobile device moving around changes

their environment. Whenever a packet is sent over

a wireless network interface, the environment of the

interface is consulted to decide which interfaces are

currently in range to receive the packet.

This allows to test the conﬁguration of the services

involved in handling mobile devices. As an example,

for employees connecting their notebook from out-

side the network using a VPN

, security policy might

require that they can not access a ﬁle server with con-

ﬁdential ﬁles. However, if the same employee takes

his notebook to the ofﬁce, he must be able to use all

services. This example also shows that in conﬁgura-

tion tests, mobile does not automatically imply wire-

less. The concept can also be used with devices con-

nected to different networks by cables.

Mobility has not only an impact on the simulation

framework, but also on the mobile device’s run-time

conﬁguration. When changing from one base station

to another, the mobile device might also change its IP

address and default gateway, which can be static or

received dynamically via DHCP. Once the mobile de-

vice has an IP address, its behaviour in the new envi-

ronment can be tested using the appropriate test cases

with input events and expected outcome. However,

this dynamic conﬁguration has to be achieved by sim-

ulating network protocols. As the ﬁnal aim is to have

a correctly working real network, we need a realis-

tic simulation. Environmental acquisition can not be

used directly to update the mobile device’s conﬁgura-

tion.

5 CONCLUSION

In this paper, we presented the concept of envi-

ronmental acquisition proposed in (Gil and Lorenz,

1996). We then explored the application of this con-

cept to network management and network simulation.

The network deﬁnes a natural containment struc-

ture to acquire information from. Additional contain-

ments not directly visible in the network topology,

like rooms or ﬂoors, can be taken into account too.

The concept is quite powerful in order to reduce re-

dundancy and thus ensure consistency of conﬁgura-

tion data. At the same time, the effort to change the

conﬁguration is diminished. Even changing a setting

that affects all workstations like the name of the ﬁle

server can be done in one place and all stations are

updated accordingly.

Virtual Private Network is a standard to tunnel a con-

nection over an untrusted network into the local network.

For simulation, environmental acquisition helps to

model mobile devices moving in and out of reach of

other wireless stations. Because we are interested in

the correctness of conﬁguration and not in the details

of wireless protocols, acquisition allows us to simu-

late exactly the level of detail we need.

REFERENCES

Abrahamson, C., Blodgett, M., Kunen, A., Mueller, N., and

Parter, D. (2003). Splat: A network switch/port con-

ﬁguration management tool. In Seventeenth Systems

Administration Conference (LISA 03), Berkeley, CA,

USA. Usenix.

Anderson, P. and Scobie, A. (2002). LCFG - the Next Gen-

eration. In UKUUG Winter Conference. UKUUG.

Buchmann, D., Jungo, D., and Ultes-Nitsche, U. (2005).

Automated conﬁguration distribution in Verinec. In

Proceedings of the 2nd International Conference on e-

Business and Telecommunications Networks (ICETE

2005), Reading, UK. INSTICC Press.

Burgess, M. (1995). Cfengine: a site conﬁguration engine.

In USENIX Computing systems, volume 8, University

of Oslo, Norway. Usenix.

Gil, J. and Lorenz, D. H. (1996). Environmental Acquisition

– A New Inheritance-Like Abstraction Mechanism.

In Proceedings of the 11

Annual Conference on

Object-Oriented Programming Systems, Languages,

and Applications, pages 214–231. OOPSLA’96.

Jungo, D., Buchmann, D., and Ultes-Nitsche, U. (2004).

The role of simulation in a network conﬁguration en-

gineering approach. In ICICT 2004, Multimedia Ser-

vices and Underlying Network Infrastructure, Cairo,

Egypt. Information Technology Institute.

Jungo, D., Buchmann, D., and Ultes-Nitsche, U. (2005).

A unit testing framework for network conﬁgurations.

In Proceedings of the 3rd International Workshop on

Modelling, Simulation, Veriﬁcation, and Validation

of Enterprise Information Systems (MSVVEIS 2005),

Miami, Florida, USA. INSTICC Press.

Jungo, D., Buchmann, D., and Ultes-Nitsche, U. (2006).

Testing of semantic properties in XML documents.

In Proceedings of the 4rd International Workshop on

Modelling, Simulation, Veriﬁcation, and Validation of

Enterprise Information Systems (MSVVEIS 2006), Pa-

phos, Cyprus. INSTICC Press.

Lhotka, L. and Novotny, J. (2002-2005). Netopeer. Tech-

nical report, Cesnet, http://www.liberouter.

org/netopeer/.

Logan, M., Felleisen, M., and Blank-Edelman, D. (2002).

Environmental Acquisition in Network Manage-

ment. In Sixteenth Systems Administration Conference

(LISA 02), pages 175–184, Berkeley, CA, USA.

Page, B., Lechler, T., and Claassen, S. (2000). Objek-

torientierte Simulation in Java mit dem Framework

DESMO-J. BoD GmbH, Norderstedt.