4.4 Evaluation
4.4.2 Generic Network Simulation for ANSE
4.4.2.1 Description
The network we're dealing with here is composed from 3 nodes (or terminals) see gure 4.28. According to the TSL network speci cation, every node in the network must have its own trac generator for and must be connected to a router. The smaller network made up from nodes local and remote (used in theActiveSPECexample)
is a sub-network in this network, while node C is element the current larger network. Note that an algorithm was devised for the automatic generation of the TSL le. As mentioned before the user must to write the object de nitions and link them together. Please refer to the description given earlier on how the net-list section's elements are generated (using the following recursive pseudo-algorithm) :
Figure 4.28: The ANSEd generic network model showing the PING network model and Node C
Repeat for all networks element the main network: 8network (large) [ 8 network (every network element this larger network) [ 8node i 2 network
trafficGeneratornode i9 1 router ]
8node (every node directly in that larger network) trafficGenarator node 91 router ]
4.4.2.2 The Result
The next gure 4.29 shows the generated TSL le from the given network in g- ure 4.28. And after running the simulator on the computer, theresult shown is iden- tical to the original example given on the web [10]. Note that the network topologies are identical with the only di erencein the names of the variables utilized (i.e. node names and router names). The gure 4.30 shows the results.
Figure 4.30: The simulation result
Throughout this thesis we explain the constructs of common logical abstractions, that combine two methodologies for the design of Active Networks. Also the example given shows how we can generate two di erent types of analyses for a network. The rst publishes anActiveSPECformal speci cation. The other publishes and invokes the
ANSE simulator on a TSL-network. Figure 4.31) shows a graph that depicts how a small network that was used in both ActiveSPECand ANSE. And gure 4.32) is a
graph that was used in ANSE. The exibilityand power of
A
CASEis in the fact that thesame network architecture can be used in both systemsActiveSPECand ANSE (see
gure 4.31) The gure 4.32 shows the topology of the network: three nodes/terminals with their packet generators and routers. There are two areas surrounded by a dotted area I and II. These areas represent in ANSEd the two modular objects trying to connect. In ANSEd every object of the type node is assigned a trac generator object and is attached to a router. Note that the intuition is that every whole network has one main router by which it can connect to the outside world. To elaborate even more, if our network was to be incorporated into a yet larger network, then there would be a router assigned for that network. For a simple network as shown gure 4.31, one router is enough to connect both nodes. While this router plays the role of connecting both nodes (local and remote) together, it also plays as an outside connection. Note that the user has the choice to pick which trac generator to attach to which node or even router, but ANSEd will make sure that the network's topology is translated
local remote
Figure 4.31: The small network used in ActiveSPEC and ANSE correctly into TSL.
4.4.3 Conclusion
A crucial functionality in
A
CASE was the correct generation of the PING speci -cations. In order to prove that the tool really ful lled its intended goals, we had to compare the results to older established examples. We decided to design similar systems and compare and contrast. We entered the same kind of constructs (i.e.
services,p olicies, p ost-conditions) that were used in those examples, in addition to the
same instantiation values (i.e. local and remote addresses). The same theorems were re-used for the veri cation parts. After generating the modular speci cations, we ran the theorem prover on the generated le. We followed the exact proof strategies
that were undertaken in those systems and we reached the same exact results. This method demonstrated at best that our system was error-free and that we had attained ourgoals.
A
CASE o ers a mechanism to combine two very useful tools in the speci cation andsimulation of networks: ActiveSPECand ANSE.
A
CASE makes use of the
Orbit-
local remote 00000 00000 00000 00000 00000 00000 11111 11111 11111 11111 11111 11111 00000 00000 00000 00000 00000 00000 11111 11111 11111 11111 11111 11111 000000 000000 000000 000000 000000 000000 000000 111111 111111 111111 111111 111111 111111 111111 Node C Router B Generator Traffic Traffic Traffic Generator Generator Router A
I
II
Figure 4.32: The largenetworkused in ANSE
Gravitydesign framework, support and abstract data model in order to achieve its
goal. As described earlier,
A
CASE produced speci cations identical to those generatedbyActiveSPECand ANSE on the same models.
Literature Survey and Related
Work
5.1 Introduction
Almost all currently published articles related to active networks is about work which is still in its research stages and almost no active networking activity is applied in commercial systems. The currently \active" systems are, in their majority, restricted to the labs of universities. The projects that are being developed aim to provide in one way or the other a suitable environmentwhere the multipleactive networking features and uses can be applied. The active networking community's main aim is to solve or o er a substitution for the current problems in existing networks [6, 7, 15, 32, 33].
This chapter will brie y describe the work in the above mentioned areas. Though proposals for active network architectures, applications and implementations are rel- evant to the broader active networking e ort, our work is more closely related to the integration of di erent active networking tools, hence heterogeneous analysis, and graphical formalism. Therefore
A
CASE and consequently its corresponding tools willbe compared to somewhat similar systems.