SERVAL: an Internet software VLAN switch developed in Erlang ∗

Alejandro Garcıa Castro, Francisco Javier Moran Rua

Igalia Software Engineering

Gutenberg, 34B 2o, Polıgono de A Grela – 15008 A Corunha

e-mail: {acastro,jmoran}@igalia.com

Juan Jose Sanchez Penas

University of Corunha, Computer Science Department

Campus de Elvinha – 15071 A Corunha

e-mail: juanjo@dc.fi.udc.es

Abstract

There are situations in which it is very interest-ing to connect a machine to a different Local Area

Network from the one its network card is actuallyconnected to. Some network applications requireour local host to be virtually connected to a remoteLocal Area Network . This article describes a pro-posal to develop a software system that emulatesthe operation of a switch, allowing to create Virtual

Local Area Networks over the Internet, that com-pletes the current similar solutions. We have cre-ated a prototype developed with Erlang/OTP usinga client/server architecture and we are working onthe integration with the Operating Systems usingvirtual network interfaces. Erlang is very suitableto face the main issues of this system: performance,communications and fault tolerance. We have ac-complished performance and functional tests to as-sess the suitability of the designed system using theprototype. The paper will explain the current re-sults of the research and describe future work.

1 Introduction

SERVAL is a research and development projectwhose aim is to assess the feasibility of a systemfor creating Virtual Local Area Networks (VLANs)using a software server. The main goal of this soft-ware is to provide a way to set up VLANs between

∗Partially supported by Xunta de Galicia - PGID-

ITSIN0313E

computers, no matter their location or the con-nection they use to access the network. For thispurpose, we have designed a system that emulatesthe operation of a hardware switch. The Operat-ing System in the client does not have a regularnetwork interface, but a special program that, act-ing as a virtual interface, communicates with theSERVAL server. The clients can connect to VLANs

defined inside the server, which works as a softwareswitch forwarding the messages between the clientsin the same Virtual Local Area Network (VLAN ).

Nowadays the solutions available to link two Lo-

cal Area Networks (LANs) do not provide some fea-tures that would be desirable in some cases. Themain technologies for connecting remote LANs cur-rently are: Virtual Private Networks (VPNs) andVLANs . The applications we have in mind as inter-esting examples to be implemented on top of thistechnologies range from mobility solutions to filesharing.

The main issues of this project that we have toface are:

• Client/server architecture: we have to supportthis kind of architecture because the connec-tion from local range IP addresses is a require-ment, and therefore P2P solutions would notsatisfy our needs.

• Performance: the emulation would have nosense if we do not have suitable latency andthroughput. The system should be able toovercome stress situations. Scalability is alsoan important feature.

1

• Operating System integration: the interfacesto our switch in the client side must be vir-tual network interfaces. User space applica-tions would use these interfaces as the regu-lar ones. Our target Operating Systems areGNU/Linux and Microsoft Windows.

• Communications security: this kind of systemsshould assure their communications, becausethe traffic goes through an unsafe medium.

We have designed a system following these re-quirements: a client/server architecture aimed tosolve the main risks we have detected. We havedecided to use Erlang/OTP [1] as the developmentenvironment because its features fit very well withthe project goals.

In this research we want to face and measure themain risks we can see to develop a system like theone we describe. The paper will explain the currentresults of the research and describe future work.

In Section 2, the current alternative solutions forconnecting remote LANs are described, and theiradvantages and disadvantages discussed; the moti-vations for the project are also presented. In Sec-tion 3, the main goals and system requirementsfor the research and development project are ex-plained. After that, Section 4 introduces the sys-tem architecture, leaving for Section 5 the detailsrelated with the use of Erlang inside the system.Current status of the project, including some per-formance tests, is presented in Section 6, beforeconcluding in Section 7.

2 State of the art and motiva-

tion

Nowadays technology brings us some options toconnect remote LANs , but these applications donot provide us features that are very interesting insome environments.

We could use Virtual Private Networks (VPNs)to create a virtual connection between remoteLANs communicating over possible untrusted net-works. With this technology we can communicateremote networks emulating neighbor networks witha router in the middle. But using this kind of tech-nology we can not transmit non-routed traffic be-tween the network (therefore, local area protocols

cannot be used). Besides, we need to configure arouter to send out the packages. An example ofthis kind of software is FreeS/Wan [2], which imple-ments IPSec [3], an standard protocol for encrypt-ing IP traffic between two networks connected bytwo IPSec gateways.

Another option would be the use of Virtual Lo-

cal Area Networks (VLANs) connecting Local Area

Networks that are physically separated, enablingnon-routed traffic between networks (and thereforelocal area protocols). Virtual Local Area Networks

are normally implemented using the 802.1Q [4] pro-tocol, which sends layer two traffic with Virtual Lo-

cal Area Network information to define Local Area

Networks using ports of different switches. The factof being able to communicate any kind of trafficbetween the networks, would simplify some reg-ular tasks when we share resources and will alsoenable the use of applications that communicatewith each other using protocols like Rendezvous orSMB. The main limitation of this kind of solutionsis that, nowadays, we can only deploy a system likethat if we have control over all the physical switchesplaced between the host and the network we wantto connect it to; besides, all the intermediate ma-chines should have that feature implemented. Wecannot forget that a telecommunications company,even controlling all the hardware of the network,can not touch the configuration of their machinesdynamically in a safe way, because any mistakewould spoil all the traffic of the network. We alsohave to remark that changing the configuration ofthe machine is not simple, and a trained technicalassistance would be needed.

The system we propose in this paper can emulatethis VLANs behavior using a scalable, distributed,TCP/IP server that acts as a software switch. Theclients would run programs that simulate logicalnetwork cards connected to the software switch.

We have taken some features of both VPN andVLAN systems to define the main goals of theproject. The security of VPNs is a very im-portant feature, because communications are per-formed through an unsafe medium. Authenticationand authorization are a important issues that needsto be solved properly. Hardware switches are de-signed to handle a great flow of packages, thereforethe system has to be ready to manage heavy stressconditions. The performance is another main issuewe have to face and specifically the system scala-

2

bility. We should consider a group of thousands ofclients that define a group of VLANs trying to sendtheir discovery messages through the switch, the la-tency has to be correctly handled. In any case, theuse of this kind of systems must be well designedbecause the amount of traffic that the local proto-cols produce can be very large.

Some of the standards and well-known technolo-gies we are using or considering for the project are:

• Local Area Network technologies: Ethernet,Token Ring, etc. We also should review sys-tems to manage this kind of traffic, congestionmanagement.

• Virtual Local Area Network technologies:802.1Q [4], 802.1D [5] and current hardwarethat supports it.

• TCP/IP transport protocols: UDP and TCP.We want to do research about which oneshould be more appropriate.

• Application level protocols and their encryp-tion systems: SSL and TSL [6].

• Network interface emulation, both forGNU/Linux and Microsoft Windows.

We have discussed and proposed some applica-tions of the SERVAL technology together with R,

Cable e Telecomunicacions de Galicia, S.A., tolearn more about possible use cases and increasethe knowledge about the system requirements. Theidea was to find out some applications in which theadvantages of the technology would make them spe-cially interesting for our project:

• Virtual corporative LANs among several phys-ical networks in a company, with a simple andflexible configuration. Enterprises could de-fine communications between their headquar-ters easily, they could even work from home,using their personal Internet connection, butaccessing the network and resources of thecompany. This is very interesting for mobil-ity: if a worker is in a different place than therest of the company, he can still connect tothe network and develop his tasks or access toa document that he has in his account.

• File sharing: users could easily create a pri-vate network between them to transmit infor-mation. They just have to use standard localarea network protocols and they could shareresources and services.

• Games through Internet that could only beused before in a LAN environment. This is aninteresting product for a telecommunicationsprovider company like, because the easiest wayto play in a network is using machine and soft-ware discovery protocols that only work in aLAN . The tool to manage the connections tothe VLANs can be an easy interface that al-lows a regular user to connect to this networksand play network games the same way he/sheis used to do in local environments. The enter-tainment industry is nowadays an importantpart of the telecommunication business.

3 Project goals

The main goal of this research is to assess the fea-sibility of the use of the current technologies forbuilding a software system able to create and con-trol VLANs . We have agreed some functional re-quirements that the developed system should fulfill:

• Client/server architecture: the basic architec-ture of the system should have these two lay-ers. We need this kind of architectural designbecause of the current Internet connectivity,there are a lot of conditions where the clientsare in a network with local IP address range.In these cases we need this kind of architectureto assure the connection between the hosts, be-cause P2P technologies would not adapt cor-rectly to our needs. The flexibility and controlthat the server application provide us seemsto be an interesting feature for the system.Anyway, we have also considered the peer-to-

peer (P2P) architecture, there are some condi-tions where the P2P could be a good solution.Therefore, our main goal is the client/serverarchitecture but we will consider the way toadapt the system to a P2P deployment.

• GNU/Linux and Microsoft Windows link layerintegration: it is an important point for thesystem usability. Due to these requirements

3

we need a multiplatform development environ-ment, able to produce software to be run inboth GNU/Linux and Microsoft Windows. Theperfect integration of the client with the Op-erating System lets us use the regular facili-ties and programs with SERVAL transparently.The Operating System will detect a new net-work interface that will use to transmit trafficlike any other interface of the system. The in-tegration with current local area technologieslike Ethernet will also be a very interesting tar-get because of the facilities that include. Thisis one of the main risks of the project, espe-cially in the Microsoft Windows environments.In GNU/Linux we already have a virtual Ether-net driver (TAP) that lets us redirect the trafficto a user space application. Microsoft Windowsenvironments are closed and the assess of thesolution is not so easy, we will have to developa system virtual driver.

• Performance: it is also a very important riskof the research, because we have to accomplishsome minimum results in order to be able toproperly emulate a LAN . The latency of theserver is an important issue to solve: we haveto reach a minimum latency even under stressconditions. The throughput should also beoptimized, because we could loose too muchbandwidth using the system. Regarding thissubject we have to consider the scalability ofthe system, which should be the best solutionfor being able to handle a lot of concurrentusers at the same time. We also have to thinkabout the transport layer protocol used for thetransmission: UDP or TCP; it seems that de-pending on the concrete conditions, one alter-native could be better than the other, so thisfeature should be configurable.

• Fault tolerance: the system should be designedto continue working in the presence of softwareor hardware failures. The server could be de-ployed in a cluster of computers, and the de-sign of processes and protocols should take intoaccount any possible problem derived from anykind of error.

• Security: one of the most important featuresthat the system should accomplish is to securethe connections; even the performance could

be penalized in some conditions. Authenti-cation, authorization and encryption shouldbe added to the system, and the connectionsshould be assured to avoid security problems.There are applications of the system wheresecurity is not an important issue but whenwe want to transmit sensitive information wemust assure the communication.

• Heterogeneous LAN protocol encapsulation:regarding the type of protocols we should sup-port at least Rendezvous and SMB. Anyway,it is very interesting to support other networktechnologies, being the optimal solution thatthe virtual interface had no difference with therest of the network interfaces of the system. Ifwe completely implement the virtual Ethernetdriver we can accomplish this goal.

4 Software and hardware ar-

chitecture

When we thought about building a system that em-ulates VLANs in a WAN environment, we had todecide the global system architecture we were go-ing to use. It should be noticed, before going onwith the detailed description, that, by global archi-

tecture, we mean both the hardware and softwareskeletons of the system.

The first option we evaluated was whether a peer-

to-peer approach would be interesting. With theuse of a peer-to-peer a approach, the scenario wouldbe the following one:

Each user of the system would have in his com-puter a client of the SERVAL system installed. Thisclient would negotiate a connection with anotheruser having also installed the SERVAL program.Once the connection between the clients was estab-lished, they would be connected at link layer level,being this medium Ethernet compatible. Therefore,the Operating System of each computer would seethe other one as if it was in its LAN with all theadvantages this fact has.

This scenario looks fairly attractive but has sev-eral serious drawbacks that made us reject it as ageneral target architecture. The main disadvantageis that if both clients are in private networks, withprivate network IP addresses, then the peer-to-peer

connection would not be feasible.

4

Another drawback is that this skeleton is notgood if we want to emulate a lot of machines inthe same LAN . This is so because the program ineach client would have to open a peer-to-peer con-nection with each computer belonging to the sameVLAN . This would cause a serious network over-head. For example, if we wanted to have a hundredusers in a VLAN , the number of connections whichwould be necessary in order to open in each com-puter is one hundred and, altogether, they wouldbe up to ten thousand. Besides, this skeleton wouldnot be persistent and each client needs to know theaddresses of all the other clients we want to includein the same emulated LAN .

A second architectural possibility to solve thesystem scalability problem with the number of con-nections would be a bus structure. This can beviewed as an improvement of the peer-to-peer ap-proach. In the bus architecture approach, the pro-grams would be joined forming a line. Hence, inthis one-dimensional structure, clients would prop-agate messages in order they reach their final des-tination.

The bus architecture, as we can see, reduces thenumber of opened connections because each SER-VAL program only has to be linked with two moreusers and the configuration complexity is lowerthan the peer-to-peer . However, it still has two im-portant drawbacks: the connection among privateIP clients, which is not possible, and how a clientcan belong to several VLANs . Another problemis the different latency of the messages dependingon the position of the clients involved in the com-munication. Therefore, the bus architecture is notsuitable to fulfill our requirements either.

After having discarded the previous system ar-chitectures, we came to the conclusion that the onewe were looking for, more adapted to the projectneeds, was the client/server model.

In the client/server model the entities taking partare the following ones:

Server The server will be a program running as adaemon in an Internet accessible host. Thisprogram, the SERVAL server, will listen forconnections coming from the users of the sys-tem. Its function is similar to the function ahardware switch has in a LAN . It will be ableto group users in different independent setsand will be the mediator among the clients.

When a user wants to send a message to an-other client, he has to send it first to the serverand, then, the server forwards it to its final des-tination. The fact that the server can groupusers in sets can be compared to the VLANs

existing in some hardware switches.

Client The clients in this architecture will be theusers who want to connect to our system.They will have to install in their computersthe client program to access the virtual switchand through it, the rest of clients.

The user Operating System, accessing theSERVAL client, will be able to see the otherclients in his groups as if they were in the sameLocal Area Network .

With the client/server model, the drawbacks andlimitations existing for a P2P or bus architectureare overcome. In order to communicate the clientand the server, operations and messages similar tothe ones used in the link layer protocols were de-fined.

The messages interchanged between the clientand the server are shown in Figure 1. The clientcan connect and disconnect to the server, ask forthe list of available VLANs , and join or leave oneof them. Other messages allow the client to send amessage to a given VLAN (and therefore to all theusers connected to it).

Other important messages are theaddressOfClientRequest and its answer fromthe server side: the addressOfClientResponse.They were created to emulate the ARP Ethernetlink layer protocol and are used when at networklevel a client wants to talk to another.

At network level clients communicate with eachother knowing their network level address. Forinstance, if we are using TCP/IP knowing theirIP. However, at link level it is not enough withthe IP address to contact with the destinationbut it is necessary to know the link layer ad-dress of the next hop towards the destinationas well. Therefore, in SERVAL we use the twoformer messages, addresssOfClientRequest andaddressOfClientResponse, to find out the SER-VAL link layer address of a client knowing its net-work address.

Finally, the global architecture chosen has to beboth fault tolerant and scalable. By fault tolerance

5

we mean the system should be resistant to a partialsystem crash, being able to overcome the situationand continue the normal operation. By scalabilitywe mean that if the system requirements grow, andthe number of clients connected is higher than theinitially expected, new resources can still be addedto the server in order to increase its performanceand fulfil the new requirements.

With this goals in mind, we have extended theclient/server model to be a distributed system. So,in the final architecture, instead of having only anode of the SERVAL program running in a host,we have several nodes which collaborate with eachother: they will detect a node failure and restartit if possible, the clients of a crashed node will bemoved to another node of the cluster, and so on.

5 Implementation of the sys-

tem using Erlang

As explained in the previous section, we have tobuild three software artefacts:

• SERVAL server. It is the program which playsthe role of a hardware switch in a real VLAN

environment. It has to be run in an IP accessi-ble from all clients. Its function is to manageall the operations related to both the VLANs

and client management. For instance, it ac-cepts input connections from clients, createsVLANs , routes messages among clients etc.

• SERVAL client. It is the software which clientsmust use to access the server. It has two parts:

– User land adapter It is the program whichreceives Ethernet frames from the virtualEthernet driver and maps them to mes-sages of the communications protocol.Next, these messages are sent to server.

It has also an interface to receive requestsdirectly from user. For example, requeststo join VLANs , to abandon them etc.

– Virtual Ethernet driver. It is an Ethernetdriver which implements a virtual net-work card. It controls the communica-tions with the Ethernet Operating Systemkernel API and the user land adapter.

Figure 1: Messages interchanged between clientand server

6

Figure 2: Relation between the client and Ethernet driver

A diagram which summarizes the relation be-tween the client agent developed and the virtualEthernet driver is shown in Figure 2. It shows howan end user application running in a computer con-nected to a server would use the client and the com-munication protocol stack. The messages sent bythe application level program are encapsulated intoa transport level protocol. Then, the transport pro-tocol is encapsulated into a network level one. Af-ter this, the network level datagrams are convertedinto Ethernet frames which, next, are sent throughthe virtual Ethernet interface. This virtual interfacedelivers the frames to the user land adapter which,finally, maps them to the protocol messages usedto communicate witch the server. They are encap-sulated through the protocol stack again and aresent by a real network interface.

The reverse path is followed by the messages de-livered to the user agent by the real network in-terface after the demultiplexing which happens onascending the communication protocol stack.

In the rest of this section, we detail the Erlangimplementation of both the server and the clientagent.

5.1 Server implementation in Erlang

The process structure of the multinode switch canbe observed in Figure 3. They are represented theprocess classes and the relations existing amongthem. The relations we emphasize are two:

• Creation link relation. A process class A hasa creation link relation with a process class B

when processes of class A create processes ofclass B. This relation type is shown by the con-tinuous lines.

• State link relation. A process class A has astate link relation with a process of class B

when in the state of processes of class A isstored the process identifier or the registeredname of processes of class B. This relation typeis represented as dotted lines.

The task each process class carries out is ex-plained to understand the Erlang implementationof the virtual VLAN switch accurately.

serval app This process class is an Erlang ap-plication behavior. It has been created tostart/stop the server.

7

serval sup This process class is an Erlangsupervisor behavior. It supervises theserval server logger, serval tcp port manager

and serval udp port manager process classes.

serval server logger It is an Erlang genericserver behavior. It has the mission of loggingall the information sent by the other processesexisting in a node.

serval tcp port manager This one is anothergeneric server. It listens on a TCP port wait-ing for incoming connections. Every time itreceives a connection request it spawns a newprocess called serval connection manager.

serval udp port manager It is also imple-mented as a generic server and its functionis to listen on an UDP port waiting forincoming messages. When it receives thefirst message coming from a source socket(source IP, source port) spawns anotherprocess, serval connection manager, forthat connection.

serval connection manager It is a super-visor and is entrusted with the task ofcoordinating and supervising the ser-

val connection communications tcp, ser-

val connection communications udp andserval connection operation process classes.

serval connection operation It is a genericserver. This process carries out the operationsassociated with the messages sent by the client.

serval connection communications udp

This process class does the sending ofmessages from the virtual switch to theSERVAL user agents. The messages whicharrive from the clients to the server arereceived in UDP communications by theserval udp port manager.

serval connection communication tcp Thisprocess class does both the receiving of themessages which arrive to the server fromclients and the delivery of the messages sentby the virtual switch to the user agents.

Figure 3: Link process class diagram

5.2 Client implementation

Regarding the user agent implemented in Erlang,the process diagram of the design can be observedin the Figure 4.

The process classes which take part in the useragent are:

serval test client gui This process control theinterface which is used to make requests to theserver and to send and receive messages fromVLANs .

It is the process which talks to the graphicssystem and receives all the events from it whenusers click in the interface widgets.

serval test client Processes of this process arecreated by the serval test client gui when theuser requests a connection with the server.

It is the process entrusted with the task ofsending messages to the SERVAL server andreceiving from the Internet all the informationsent to the client.

8

Figure 4: SERVAL user agent link process class di-agram

5.3 Storing VLANs information in

Mnesia

In Section 4, it was stated that the project goal wasto build a scalable, concurrent and fault tolerantsystem.

To achieve this target, we decided to make ourvirtual switch a multiple node software. We meanthat in our architecture we have several instancesof the SERVAL application which can attend clientrequests. Therefore, clients can connect to any ofthe nodes of the server, and independently of thenode they access they see each other and the sameVirtual Local Area Networks . In other words, thismeans that a client connected to a node A has to beable to send a message to another client connectedto a node B if both belong to the same VLAN .

In this multinode architecture, then, it is neces-sary to have communication among nodes to shareVLANs information. We decided to use Mnesia, adistributed database management system includedin Erlang/OTP. With this distributed database wecan access information of the existing VLANs andclients connected to each of them from any of thenodes of the system.

The use of Mnesia has big advantages for thisproject. Thanks to its distribution capabilities,synchronization among nodes is done automaticallyby this DBMS and it is transparent to SERVAL. Inthis way, as we rely on Mnesia, synchronization ofthe virtual switch nodes is done without overload-ing the code with synchronization tasks. This ideais represented in Figure 5, which shows the situa-tion in which there are three nodes running belong-ing to the SERVAL cluster. It can be observed howeach of the nodes has a local copy of the distributedMnesia tables and how the communication among

Figure 5: SERVAL server cluster with 3 nodes

nodes is done using the database.

5.4 ASN1 Erlang compiler for com-

munication protocol implemen-

tation

We decided to use the Abstract System Notation

One - ASN1 for the definition, transmission andencapsulation of our internal, client/server, com-munications protocol.

ASN1 is formal language for abstract descriptionof the messages interchanged in communicationsprotocols, with independence of the programminglanguage chosen and the data memory representa-tion. ASN1 is a standard since 1984 and, conse-quently, its codification framework is mature andit has been used successfully in a lot of differentscenarios.

In the project we have used the Erlang ASN1 com-piler. This compiler in very useful because it gen-erates coding and decoding functions which can bedirectly used by Erlang programs.

5.5 Process collaboration scenarios

In this section we describe several collaboration sce-narios with the aim to understand more accuratelyhow the SERVAL system works.

5.5.1 SERVAL server starting

When the SERVAL server is started, it is launcheda process of class serval app. Next, the ser-

val app spawns three more process of class ser-

val server logger, serval tcp port manager and ser-

val udp port manager respectively.

9

Our SERVAL server has support to maintaincommunications with the clients using as trans-port protocol TCP or UDP. This is the rea-son why, when the SERVAL server is launched,the processes serval tcp port manager and ser-

val udp port manager are created. The first listensfor input connections in a TCP port and the secondlistens for packets in an UDP port.

5.5.2 SERVAL client connection request to

SERVAL server

We are going to explain what happens when a clientrequests a TCP connection with the SERVAL server.

First an open port TCP message is re-ceived by the process serval tcp port manager.Second, this process creates a process ser-

val connection manager and, then, this lastone spawns two more processes, a ser-

val connection communications tcp and a ser-

val connection operation.

With these three processes we have the structureto manage all the operations related to the clienthas requested the connection.

5.5.3 Message interchange between pro-

cesses belonging to the same VLAN

When a client A wants to send a message to an-other B, first, A has to find out B client identifierknowing its network level address. In order to getB client identifier, it sends the SERVAL server aadressOfClientRequest.

All clients in the same VLANs that A, receivethis addressOfClientRequest. The one whosenetwork level address matches the one included inthe message, that’s to say B, sends back to A anaddressOfClientResponse with its client identi-fier.

Next, A sends the SERVAL server asendMessageRequest with the data and theB client identifier as destination address. TheSERVAL server checks that B is in the same VLANs

and, if this condition is true, delivers B the mes-sage. After this, sends A a sendMessageResponse.

We can observe all this behaviour in the figure 6.

Figure 7: Client screenshot

6 Current status of the re-

search

6.1 The prototype GUI

In Figure 7, the graphical user interface developedfor the prototype user agent can be seen.

In the GUI window of the example, the clientis connected to a SERVAL server which is listen-ing for input connections in port 4567. The useris connected to the virtual switch through a clientwith address client1. We can see that there are twoVLANs created, vlan1 and vlan2, and that Client1

joined both. Finally, we can observe that vlan1

contains two clients with the address client1 andclient2.

6.2 Testing the system

Two key features of the system, as already ex-plained, are performance and fault tolerance. Ev-ery design and new characteristic we add to thesystem is developed thinking of what impact it willhave over these two variables. But we are not onlythink in the impact of the modifications but try-ing to measure and to check the system with thenew additions. In this subsection, some perfor-mance measurements and fault tolerance tests thatwe have carried out are described.

10

Figure 6: Message interchange between processes belonging to the same VLANs

6.2.1 Performance tests

Due to the real time nature of the system, and theamount of concurrent users that should potentiallybe able to handle, a good performance is an essen-tial requirement for the system.

We have concluded that the performance in SER-VAL can be measured by the two following vari-ables:

• Operation latency. The operation latency isthe time it takes an operation to be completed,since it is ordered until it is finished. The lowerthe operation latency, the higher the systemperformance. As final goal, we are speciallyinterested in reducing the message latency of amessage sent from a client to another throughthe server.

• Throughput. The throughput of a system isthe number of operation requests it can han-dle in a period of time. A higher through-put means that the system is able to carry outa lot of operations concurrently. We shouldalso consider the bandwidth reduction caused

by use of our internal protocol. We increasethe size of the packages internally, becausewe need to store some extra information, weshould keep them small to enhance the use ofthe medium. Currently we do not consider thisincrement of the size of the packages a prob-lem.

In order to make these measurements we have de-veloped a special module for creating performancegraphics. It is call serval gnuplot and uses the GPLapplication gnuplot.

With this module carried out performance testsin both the client and server side. We will describetwo examples in which we have obtained perfor-mance improvements after analyzing the operationlatency and the system throughput.

The get vlans message This protocol messagehas a latency which grows with the number ofVLANs . So, the high latency of this message blocksanother messages in the server queue, which cannotbe delivered by the server quickly.

After some performance tests, the Mnesia query

11

for getting all the VLANs created in the server,was pointed out as the system bottleneck for thisoperation.

In figure 8 we can see the time process theget vlans with different number of VLANs createdin the server.

We have represented also the VLANs numberagainst the get vlans latency. The graphichs ob-tained can be seen in figure 9.

The impact in the latency of the messages thatthe number of VLANs created in the system has,can be easily observed.

The solution we chose to solve this problem wasthe use of a memory cache to speed up the requestoperation. So that, with this cache we were able torise up the throughput of the virtual switch and,besides, we could drop the latency of the get vlans

message.

The adressOfClientRequest message Afteranalyzing the system operations performed duringthe message interchange between the clients of thesystem, we detected that the number of addres-

sOfClientRequest sent by the client agents was toohigh.

Many of these addressOfClientsRequests mes-sages, however, were asking for the address of thesame client. Hence we implemented a cache inclient side to store the mapping between networkaddresses and the SERVAL identifiers.

Doing this we got a double improvement. First,we reduced the number of addressOfClientsRe-

quests messages sent to the SERVAL switch drop-ping its average load; and second, we decreased thelatency of this message. In Figure 10, we can ob-serve how with the client address cache the numberof get addr messages received in the server is lessthan the number of the other message types.

6.2.2 Fault tolerance

To have fault tolerance features was already statedin Section 3 as an essential goal for the project.

There are different strategies which can be fol-lowed to create a fault tolerant system. In our case,the concurrency and distribution properties of Er-lang have allowed us to build a robust recovery sys-tem based on the multiple node server described inSection 4.

The idea is that if a node crashes the system hasmechanisms for letting the rest of nodes continuethe work that was being carried out by the crashingone. This can be easily explained introducing somesituations and how they are overcome:

One node crash If a node crashes, the recov-ery mechanism consists mainly in the reconnectionengine implemented in the clients.

The description of this engine is as follows: eachclient receives from the server an address and portlist with all the nodes belonging to the cluster asanswer to the connection message. Therefore, whena client detects the node is connected to is unreach-able, then it requests the connection with anotherof the nodes. This second node is obtained fromthe node list that, as mentioned, is stored in theclient state.

When the server receives a connection request,it uses Mnesia to check if the client was connectedthrough another node before. We consult Mnesiabecause we use a distributed table which registerseach client connected to SERVAL. The informationwe record for each client is:

• The link layer SERVAL address. We call itclient identifier as well.

• The process identifier of the SERVAL processwe use to manage the client.

Taking this into account, we query the formerMnesia table to find out if there is a row with thesame link layer address that the one of client isrequesting the connection:

• If we get zero rows this means that the clientis not doing a reconnection because the nodeit was acceding has crashed. We record theinformation for the the new client in a newrow.

• If we get one row this fact means that the clientis doing a reconnection. Hence, we have to up-date the row obtained with the new processidentifier of the process created in the new ac-cess node to manage the connection.

Client crash This scenario describes which re-covery actions are performed when a unsuitableclient disconnection takes place, and the message

12

0

2000

4000

6000

8000

10000

12000

14000

16000

0 1 2 3 4 5

vlans_1 get_vlans Timevlans_100 get_vlans Time

vlans_1000 get_vlans Time

Figure 8: Time to process the get vlan message depending on the VLANs existing in the server

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

0 200 400 600 800 1000 1200 1400 1600 1800 2000

vlans_time get_vlans Time

Figure 9: VLANs number against get vlans latency

13

0

5

10

15

20

25

0 10 20 30 40 50 60

get_addr Numberjoin_vlan Number

leave_vlan Numberget_clients Numbersend_msg Numberget_vlans Number

Figure 10: Number of each message type received in the server

connectionCloseRequest is not sent by the clientto the server.

The client crash can be caused by a software fail-ure, but the message could be also lost due to somenetwork problem. When this happens, the pro-cesses responsible for the client management arekept alive in the node the client was connected to.Therefore, in this situation, if another client sendsa message to this crashed one, in the switch clusterthe client is detected as connected. Because of this,the switch sends the message, though it will neverarrive to its final destination, because it is down(we will explain why we do not matter this lost ofmessages).

Next, we are going to describe the strategy we de-cided to implement when the former situation hap-pens. Each client incorporates a keep alive mech-anism which sends the server a message at regularperiods of time. Each server node has a processwhich monitors the receiving of the keep alive mes-sages coming from clients. If this monitoring pro-cess detects that a client is not sending the keepalive messages and it has not requested the con-nection close, then it kills the management pro-cesses for this client. Besides, the monitoring pro-cess deletes from Mnesia the information related tothe VLANs the crashed client was connected to.

As we can observe, there is a period of time be-tween a client crashes until this fact is detectedin the server. If a message is sent to the crashedclient during this period of time, the messages donot reach the destination. We could implement ac-knowledgement messages to guarantee they alwaysarrive to its final destination. However, we do notwish a too heavy protocol because we are emulat-ing a link layer scenario. Therefore, these failuresrarely happen and will be detected by upper layersin the communication protocol suite used.

6.2.3 Future work

Nowadays, we have in mind to work on severalthings, some of which are:

Congestion control protocol We want the vir-tual server switch nodes to monitor its internalwork load. So, to succeed in this task we areimplementing the processes necessary to mea-sure this magnitude. Besides, it is necessaryto extend the link layer protocol in order it in-corporates the messages needed for congestioncontrol.

SERVAL clients are being also improved withthe ability to process the congestion control

14

information sent by the server. So, if they de-tect that the work load of the node they areaccessing to is too high, they can decide to askanother node with lower load lodge them.

Access Control List For many real environ-ments it is very important to be able to giveand revoke permissions to clients to do certainoperations or to access certain resources in thevirtual switch.

For instance, we can wish to let users with acertain profile create VLANs in our server andforbid this operation to other users groups.Another example, is the possibility to join aVLAN . A server administrator may wish tohave a predefined set of VLANs created in thevirtual switch. He may wish to have the con-trol to authorize or deny the access to eachVLAN following a per user or per group pol-icy. All this can be done implementing theACL engine and we are hands on.

Ethernet driver In the section (4) we saw that onethe components of the architecture is the inter-face with the link layer of the communicationprotocol kernel stack.

We are working in the strategy to implementthis virtual Ethernet driver. He are also as-sessing the possibility to use the TAP devicedriver. The TAP is a Virtual Ethernet net-work device. It was designed as low level ker-nel support for Ethernet tunnelling. It providesto user-land application two interfaces:

• /dev/tapX character device

• tapX virtual Ethernet interface.

The user-land SERVAL Erlang client could usethis device /dev/tapX to write Ethernet frameswhich will be received by the kernel. On theother hand, each Ethernet frame wrote by thekernel to the tapX interface will be received bythe SERVAL client by reading the /dev/tapX

device file.

Secure communications We are emulating avirtual switch, so our virtual operation envi-ronment is a VLAN . In a LAN the Ethernetframes don’t leave the network limits so thesecurity policy can be relaxed if we rely on ourVLAN users.

However, although the SERVAL server virtualenvironment is a VLAN , the real environmentis a WAN . As a consequence, all our link layertraffic is going to cross through the Internetand will be exposed to be sniffed by everybody.So we are implementing SSL support in clientand server side to cipher communications.

7 Conclusions and future

work

In this paper we have explained the main moti-vations and goals of the SERVAL project, the de-signed solution proposed to achieve them and thecurrent results and work that we are developing.Through the paper we have established that Erlangis a suitable technology for this project, where net-work communications, performance and fault tol-erance are the main requirements.

We think that our project can be interesting andapplicable in a lot of real and diverse scenarios -pointed out in the paper - in which emulating Vir-

tual Local Area Networks over Internet is a good so-lution. SERVAL Virtual Local Area Networks man-agement will allow a more flexible way of designingnetwork topologies.

We can transmit that nowadays we are satisfiedwith the results we are obtaining and with the fu-ture of the project. In fact, we are encouraged withhaving a real and almost complete SERVAL proto-type in the near future that will be the first step tobuild an actual system.

8 Acknowledgements

The authors want to thank Alberto GarcıaGonzalez, Jose Juan Gonzalez Alonso, Iago ToralQuiroga, Adrian Otero Vila and Angel Vidal, andin general the whole Igalia company, for theircollaboration in the development of the SERVALproject.

References

[1] J.L. Armstrong, S.R. Virding, M.C. Williams,and C. Wikstrom. Concurrent Programming

15

in Erlang, 2nd edition. Prentice Hall Interna-tional, 1996.

[2] The FreeS/WAN Project. Ipsec gnu/linux im-plementation, 2004. http://www.freeswan.org/.

[3] The Internet Engineering Task Force(IETF). Ip security protocol (ipsec), 2004.http://www.ietf.org/html.charters/ipsec-charter.html.

[4] IEEE Project 802.2 Working Group. IEEE stan-dard for local and metropolitan area networks:Virtual bridged local area networks. Techni-cal report, Institute of Electrical and Electron-ics Engineers, 3 Park Avenue, New York, NY10016-5997, 1998.

[5] IEEE Project 802.2 Working Group. IEEE

standard for information technology–telecommunications and information exchangebetween systems–ieee standard for localand metropolitan area networks–commonspecifications–media access control (mac)bridges. Technical Report ISO/IEC 15802-3:1998, Institute of Electrical and ElectronicsEngineers, 3 Park Avenue, New York, NY10016-5997, 1998.

[6] T. Dierks and C. Allen. The tls protocol version1.0. RFC 2246, IETF - (Internet EngineeringTask Force), January 1999.

[7] W. Stallings. Local Networks. Macmillan Pub-lishing Company, New York, 3d edition, 1990.

[8] IEEE Project 802.2 Working Group. IEEE stan-dard for local and metropolitan area networks:Overview and architecture. Technical ReportIEEE 802-2001, Institute of Electrical and Elec-tronics Engineers, 3 Park Avenue, New York,NY 10016-5997, 2001.

[9] K. Pitt, D.; Sy. Address-based and non-address-based routing schemes for interconnected localarea networks. Computer Science Press, 1986.

16