ARCHITECTURE FOR VIRTUAL ACTIVE NETWORKS OVER INTERNET *

ARCHITECTURE FOR VIRTUAL ACTIVE NETWORKS OVER INTERNET * Francisco Puentes, Fidel Cacheda, Víctor Carneiro Information and Communication Technologie...
Author: Jessie Tucker
1 downloads 0 Views 233KB Size
ARCHITECTURE FOR VIRTUAL ACTIVE NETWORKS OVER INTERNET

*

Francisco Puentes, Fidel Cacheda, Víctor Carneiro Information and Communication Technologies Department University of A Coruña. Campus de Elviña S/N, 15071 - A Coruña (Spain). Phone: +34 981167000 Fax: +34 981167160 E-mail: {fpuentes, fidel, viccar}@udc.es

Abstract: This report will describe the VAIN (Virtual Active IP Network) architecture development to response challenges outlined by electronic commerce, specifically at the collaborative environments and marketplaces. For this development we have considered following goals: a three layer conceptualization, a transparent implantation and its integration with existing infrastructures; and a strategy of network traffic distribution based on whole information from input packets, by means of the named “patterns based distribution”. Mainly VAIN uses as guest code an interpreter of intermediate code from .NET architecture, although the possibility is open to use other intermediate codes. VAIN is immediately over link layer, being able to be extended to any other similar protocol, and independent of upper protocols existing or not at the present time. Our architecture presents, also, a polymorphic character since it allows changing its behavior in a transparent way and virtually emulating other architectures concurrently without affect its functionality. Keywords: Virtual active networks, Communication architecture.

1. INTRODUCTION Active networks (networks formed by programmable devices which are able to perform tasks on demand over the traffic that crosses them) have turned into, since its proposal [1], in a special research area with excellent works and projects. Its success in the land of the investigation is, probably, because all the involved researchers understand that technologies as a step forward, opposite to traditional networks, since nowadays active networks are able to perform process of which those lack. Traditional networks (from now denominated syntactic networks too) make a special emphasis in the network structure and guarantee information delivery in a suitable time to the application that it serves. Each intermediate device that constitutes this networks are specialized to receive packets of information, perform a minimum set of tasks (typically over protocol headers and therefore it is limited to the structural aspects of communications and it ignores its meaning – this is, the packet content), compute next hop or output interface and perform packet delivery towards the wire. These networks are data exchanged systems, remained compute capacity on the extreme elements of the same one (client and server on C/S architecture, for example). We say therefore the semantics of the communication is responsibility on the extreme elements of the same one.

Actually, communication does not add meaning to the application that comprises. Active networks allow communications to comprise a special part of the application total meaning, being able to delegate over the transmission part of the logic leading the solution (this is, the application). The fact that between two distant points exists one or more intermediate nodes with the capacity to shelter logic (and therefore the active processing of the data that crosses it) have a direct consequence: a third element, data transmitter or receiver, can share logic with both, without the need that one of then become a central server or as relay of the information. Let us think about how doing this by means of a syntactic network. In this for a third element get into the communication existing between two elements, must choose one of then (or even both) to be able to access to the logic that lead the data transmission. If instead of thinking in three elements we think in many more, it is clear the logic to share will have to be centralized in one of then, promote it as a server and the remaining as clients. This is the base of C/S architecture. The same problem in an active network based architecture can be solved without the necessity of a central entity that hosts the complete logic and contributes to the communication between entities that use it. Two clients which transmit by means of an active network, and therefore having in its path at least an active node, share

(*) This dissertation have been financed partially by CICYT TIC2001-0547 project.

part of the application semantic (let us remind that active networks host part of the complete meaning of the problem to solve that it implies the information communication) and the apparition of a third (or more) entity does not imply that some of them must be promoted as a central node of a star like topology. If the meaning is the same for all the participants it can be shared over the

Input / output modules (n interfaces for each module)

network (even without knowing itself) or can be modularized and be distributed in several nodes simultaneously to support the collaboration between diverse meanings and thus be able to be reused by several participants with different or similar necessities.

User Environments (1 for user) Execution Environments (n for each user)

VAIN engine

EE Control

Majordomo (set of services) User Environment Control

down stream

Output

Input

Capture control

Static Services

up stream

Input / output modules interface

Delivering make map and select target service

Guest code

Execution Environment Guest code

Execution Environment EE Control

Input

Inject control

Static Services

Execution Environment Output

Guest code

Execution Environment Guest code

User Environments interface

Down stream Up stream Services & control flow Queue

Figure 1 : Block diagram of VAIN nodes Therefore, active networks make his emphasis in the meaning while traditional networks stress his structure. Inside active networks research, a special area is virtual active networks (VAN) [7], this is, semantic networks which do a special emphasis in the abstraction of the communications, looking for new architectures. These VAN have a clear advantage over no-virtual active networks: they are flexible and independents of the physical infrastructure that supports them. This is, given a physical infrastructure, let us put for example a traditional network, the changes that are done on these will remarkably affect the design of non-virtual active

networks, due to the fact that the design will be highly depending on address, name and devices. Although, in this paper will go an step forward, asserting that the existence of a virtual layer that contents part of the meaning not only makes the design more flexible with respect to the changes on its lower structure, but it allows new ways of thinking about communications.

2. VAIN - Virtual Active IP Network In order to demonstrate that assertion we have created VAIN, which is fitted into virtual active networks, having in mind that it will be used over Internet and the goal, at

Figure 1 shows the functional scheme of an active node into VAIN. This diagram corresponds with communication (input/output modules) and execution (user environments) layers.

3. Communication layer I/O Modules have a double goal: to isolate the node engine from the special features of the data capture and injection on the wire and to allow the isolation of the different network address formats. Although VAIN have been created to perform over IP, it can be easily extended to IPX, ATM or any other format that fulfills the requirements of a OSI net layer (or even link layer). These modules (for example “eth-ipv4-ipv4.so” file) are embedded into dynamic link libraries with a well defined interface broken into two categories: input and output, and static services. First one leading to open, close, read and writes packets over the interfaces. Static services are leading to perform addresses process services, this is, to convert addresses, compare and operate with then. Each module is able to perform both or only one of these. The VAIN node central part is the communication layer, and its operation can be better explained describing the packets that flow along this stage [see figure 2]. At the arrival of a data packet (actually to this stage it does not matter about the packet type) the packet dictionary is created. This is a process that involves a network schema [see figure 3] and its comparison with the recently arrived packets. When it finishes we will have the packet recognized (although partially) and a dictionary made up of pairs (name, value), which contains the packet recognized fields. Network scheme is part of the node dictionary (global data repository in XML format) where it is detailed the structure of the protocols that are initially accepted by the node (nowadays IPv4, ICMP, TCP and UDP) indicating its structure and fields. During the process of application of the network scheme the recognized fields are added into the packet dictionary (protocols and fields, with pointers and values). The output from this process is that: the package is recognized (total or partially) or the packet is absolutely not recognized. In the latter case it is rejected. If it is recognized we obtain its dictionary as secondary product, where we can easily find all the fields and protocols that compose it. This dictionary accepts searches of the kind “ipv4.version” returning the value 4 for a IPv4 packet; or “ipv4.icmp.echo.seq” for a ICMP packet ECHO type.

Once the packet dictionary is created, it is inserted into the upstream queue, which grant independence two threads. The deliverer sub stage gets from this queue packets and look for its target service. In order to do this, each service had submitted an expression to be evaluated that recognizes if a packet has to be dispatched to that service. Network expressions are Boolean expressions that use logic, relational, bit level and arithmetic operators, as well as functions, constants and variables. The last ones make reference to packet data dictionary items, which were created in the previous sub stage. This allows having expressions of the type: ipv4.tcp AND ipv4.tcp.port.target==8080

This expression is evaluated as true in the packets that contain IPv4 and TCP protocols and whose target port is 8080. Packet

Net’s Schema

Packet Diccionary

Net’s Patterns

Service

Apply Net’s Schema

Recognition substage

The following sections detail the architecture of an active node into VAIN and its conceptualization as three layer devices: communications, execution and virtual layer.

Also there are other possible types of searches, more complex, of dictionary items (as for example, backwards “echo.icmp.ipv4:seq” or simply “echo:seq” for an ICMP packet. This kind of search is interesting on packets where we do not know which lowers protocols will be used).

Queue packet

Select Target Service

Service

Delivering substage

medium term, is its use in electronic commerce and collaborative markets.

Service

Figure 2 : Sub stages of packet dictionary creation and the delivering of the incoming flow. Network expressions can use any field that has been introduced in the packet dictionary, combined with any

suitable type of operator. Once selected the target service of the package, this is routing through user environment interface (UE), which corresponds to the target service. The creation and use of the packet dictionary and the network expressions have as negative consequence the low efficiency, but a high efficacy. This is, although the performance is slower than other similar prototypes, VAIN allows that nodes do not know absolutely anything over the protocols it manages. This is because the scheme is stored in XML format and it allows to be changed or

completed voluntarily in runtime, and that the services indicate how recognize their own traffic. If a service implements a protocol above IPv4, for example, the node do not need to be updated due to the service will include a private portion of the network scheme and the expression that it recognizes the input traffic (typically after the public recognized portion) In the same way a VAIN node do not implements any protocol and therefore any change in the future communication syntax will not affect the VAIN nodes.

Figure 3 : Net scheme, extract from the node data dictionary.

4. Execution layer VAIN architecture contemplates the figure of the user into the active node. Due to the fact VAIN nodes are built into O.S. GNU/Linux, these use system accounts to control the access over the system resources. In concrete at the moment that the services are installed, users must identify itself against the system and all the users’ services will be hosted into a special environment called UE (User Environment). This environment grants that a weak code does not affect to the rest of the services. In addition, all the services run into an UE have access over system resources in the measurement that the administrator allow this, putting user’s quotas (disk, memory, threads, execution time, etc). UE create the first sandbox, which surrounds each service. The control sub module assures to manage all aspects from the user’s environment, since the reception of packets intended for services of its own, to the request for the installation of new services. Each service is embedded into an execution environment (EE) that controls the guest code execution (this is, the service) initiating it and allowing the communication between the native code and the guest code. VAIN implants each EE as a dynamic link library, to allow more than one way to execute guest code into an active node. For example “dotnet.so” is a specialised native code to execute the guest code from .NET Microsoft architecture. The generated code (CLI) is able to be executed into this dynamic link EE. This library is responsible of the communication between the EE and the guest code and to expose native functions to the guest code universe, and vice versa. As we can see, the guest code is embedded into two control perimeters (UE and EE), and both have different responsibilities with respect to the tasks to perform. Using dynamic link libraries to implant EE, VAIN support that a node (using different libraries simultaneously) possesses several ways to control and to execute guest code. For example “java.so”, “ants.so” and “plan.so”. Last two at medium term.

5. Virtual layer Until now we had showed the two first layers in an active node under VAIN architecture. This section treats on the virtual layer. The first layer, communications, is almost equivalent to a routing device in a traditional network. Instead of selecting an output interface (next hop) it selects a target service. If instead of having complex services, we put one simple service that get packets, look up at the routing table and compute next hop, we obtain a basic classic router. The second layer grants the independence of the services over the communications layer, isolating them into the

user and the execution environments and controlling its performance. It is a service and security layer. Instead of layers, let us think about planes. A plane is formed by devices and communications lines from the same layer. Therefore the communications plane will be the same as traditional networks. The execution plane will differ, because it only considers active nodes and the static communications between then. The projection from the second plane into the first one is trivial. If we had finalized here our architecture, our design would be highly depended of the plane structure (due to the fact that projection is trivial). In the case of a failure or simply, in the case of changes in the infrastructure, our design would not perform properly. In this case, before deploying an active network design, we would have to ask for support to the infrastructure owners. By means of the design virtualization of an active network, this is not necessary. Let us add a third layer: a virtual layer with its corresponding plane, the virtual plane. This layer is designed for the execution of the guest code into EE. This is, it is not a physical layer, as the previous two. The virtual layer is formed by the semantic of a sub set of services, the result of its execution into an EE. The service execution in this later gives VAN (Virtual Active Nodes). And virtual plane is formed by a sub set of VANs executing into theirs UE and communication lines that join together. The design of a virtual active network is the design of the virtual plane. At the moment to execute a design exists a process (service) that projects VAN over execution layer, in such a way that an active node can allow more than one. In this way and considering its requirements (that designer appended at original design) the design projection over execution plane, without being trivial, allows the isolation of our designs from the lower infrastructure. Figure 4 show three planes where the second one projects it self over the first one. Some of the devices into the first plane (communications) are active nodes. As we can see, virtual active nodes (third plane, virtual plane) are thrown over active nodes (second plane, execution plane), which for one active node can allow more than one VAN. All active nodes implant a service called (in a general manner) mapping, which is the responsible of performing the projection on external demand. Each solution can have a different service to install it along the path. Another service is XDNS, a classic DNS extension, which perform extended request to allow the resolutions from pairs [name, service] to [IP, SID] (SID = Service number, similar and compatible with port numbers in TCP/UDP). These service numbers are unique into the active node.

7. Summary Virtual Active IP Networks (VAIN) architecture encourage the view of virtual active nodes over active nodes, fulfill it into a three layer architecture and extending its functionality as far as to include virtual active node semantic. This is, mainly, our object of future study. Patterns based delivery is a powerful and flexible tool to deliver input traffic into services, allowing them to be able to be used smartly, adapting it self to any situation, present and future. Figure 4 : Three layer virtual architecture The XDNS service is implanted into an active node that managed administrative areas. Each active node that needed to comprise of the area it needs to have got a XDNS relay service that performs the local extended responses and bypasses the external ones.

6. Implantation and current state This paper has showed the active node architecture we have built to test ours ideas and to support the following developments for which it was built: electronic commerce. Nowadays the development of a VAIN active node has taken using S.O. GNU/Linux as a stand-alone program (at medium term we will implant a version that it will embed part of the node into the S.O. kernel) that contains communications and execution layers, and also some services, for testing purposes. Node efficiency under situations of high traffic is right, although its maximum bandwidth is around 1.5MBps (in a situation of constant load). From that moment the queue sizes begin to increment due to the deliverer cannot perform its tasks with efficiency. The solutions are the optimization of the evaluation of the expressions and the creation of the packet dictionary. Mainly this one, because at the moment it is realized by means of an expression compilation into trees and its interpretation is performed by means of a tree reduction. Nowadays there are betters ways to do that. Net expressions could be compiled into native code at runtime so its executions would spend a short time. For the execution environments we have chosen the .NET architecture from Microsoft because there is a version with high possibilities of integration into native code, exposing functions, methods, classes and objects. The speed of the JIT interpreter is excellent and upper to JAVA JIT interpreter. Although, the .NET architecture election is circumstantial due to the fact that VAIN nodes can support more that one language simultaneously without interfering between then.

The final reason to be of VAIN is electronic commerce and especially collaborative commerce. In this paper we have labeled an architecture that allows us to increase the semantic of a communication system, performing that logic can be shared between participants without needing a central point that coordinate then. Mainly VAIN networks allow each participant to design their own virtual active network and extend it along Internet allowing “points of presence” (services) that interact with other one from other users. The physic implantation of these designs is files that contain XML specifications from design and the compiled guest code. At this designs the user can determine where VAN will be embedded or they can delegate to the system to choose them by the grants they have designed.

Bibliography [1] D. L. Tennenhouse and David J. Wetherall, “Towards an Active Network Architecture”. Computer Communication Review, Vol. 26(2). 1996. [2] Marcus Brunner, Rolf Stadler, “Management in Telecom Environments that are based on Active Networks”. Journal of High Speed Networks, 2001. [3] Herbert Bos, Rebecca Isaacs, Richard Mortier, Ian Leslie, “Elastic Network Control: An alternative to Active Networks”. Journal of communications and networks. Vol. XX, Mar. 2001. [4] Michael Hicks, Scott Nettles., “Active Networking means Evolution (or Enhanced Extensibility Required)”. H. Yasuda (ed.) IWAN 2000, LNCS 1942, pp. 16-32. 2000. [5] María Calderón Pastor, Marifeli Sedano Ruiz, Santiago Eibe García, “Principios y aplicaciones de las redes activas”. Procedings of JITEL’99. Septiembre 1999. [6] K. L. Calvert, “Architectural Framework for Active Networks”. Active Network Working Group. 1999. [7] Gong Su, Yechiam Yemini “Virtual Active Networks: towars multi-edged network computing”. Computing Networks. 36 (2001) 153-168.