3. TCM projects |
The goal of Bengt Sahlin's project was to implement a prototype of IPv6 and IPSEC that is portable, reusable, and modular. An object oriented approach was taken and Java was chosen as the implementation language. The Conduits+ framework was chosen as an experimental framework for the implementation. The main emphasis was put on the implementation architecture, hence performance issues were considered only concerning architecture, not the prototype. IPv6 was implemented only in its minimal form to allow for testing IPSEC and manual key management was deployed.
Conduits+ is a framework for network software. It reduces the complexity of network software, makes it easier to extend or modify network protocols, and is sufficiently efficient. A key factor in designing reusable communication protocol software is how to factor out the common structure and behavior from the protocol specific parts. When using Conduits+, most of the control is the responsibility of the framework, and the programmer can concentrate on the environment.
We can list the advantages of using a framework:
Conduits+ is made up of two sorts of objects: conduits and information chunks. Information chunks are everything flowing through the conduits. A conduit is a software component with two distinct sides. These sides may be used to connect a conduit to another, neighbor conduit.
The use of the Conduits+ framework in this implementation of IPSEC provided a guarantee of modularity and reusability. Modularity is achieved because the framework allows additions to the existing software by simply building more conduits, and reusability is defined by the purpose of the framework.
The Java programming language was used as it helps fulfill the portability goal of the project. Any machine implementing the Java Virtual Machine can run Java byte code. Java also offers libraries with useful methods for protocol programming.
There are several other advantages in using Java. For more details please refer to Java documentation.
The prototype was implemented under Solaris 2.5. The Conduits+ framework and the IPv6-IPSEC parts are implemented in Java using the Java Development Kit (JDK). The Ethernet adapter is implemented in C (an ethernet adaptor is a software piece responsible for communicating between ethernet hardware and the protocol layer which uses it).
[A conceptual model of the implementation]
IPv6 has been designed to be simple, and hence the implementation architecture should follow the ideology. As little processing as possible should be done to regular IPv6 packets. Special processing, for instance the security transforms, is deferred to option headers that can be dynamically added. This means the architecture must be dynamic, and allow headers to be dynamically added to outgoing packets, and dynamically handled when receiving a packet.
As can be seen from the conceptual model, IPSEC has been implemented inside the IPv6, unlike Aalto's prototype where it was implemented below the IP layer. This illustrates how IPSEC is designed to be an integral part of IPv6, but is an add-on to IPv4. As Aalto pointed out, implementation inside the IP also improves the performance as some of the unnecessary communication between packages is cut out.
Performance was considered an issue only concerning the architecture, not the prototype. The JDK is not very mature and needs improvement.
The performance of the prototype was evaluated by sending variable amounts of data between two Sun SPARCStation 20 machines using 10Mb/s Ethernet as transmission medium:
[the test environment]
The table below shows results from the transmission tests:
| Block Size (bytes) | Ordinary IP (bytes/s) | Encrypted IP (bytes/s) |
| 1 | 14 | 7 |
| 10 | 135 | 69 |
| 100 | 1333 | 578 |
| 1000 | 11765 | 3571 |
| 10000 | 39526 | 14706 |
| 100000 | 91659 | 36928 |
| 1000000 | 149589 | 42876 |
Transmission speeds of up to 40kb/s with encryption (and 150kb/sec without encryption) have been achieved. This can be considered a reasonable performance for this unoptimized prototype. It should be possible to achieve much better results through simply by use of better, just-in-time Java compilers such as Kaffe.
Sahlin's conclusion is that Conduits+ is a good concept, and together with Java they seem to capture the flexible and dynamic nature of IPv6. There is scope for improvement within the framework itself to make the code more reusable. On final note we need to say that IPv6 is stateless, which causes a slight semantic problem as some of the functionality is implemented with the Conduits+ States. This means that perhaps Conduits+ is more suitable to protocols having many states, but definitely not restricted.
For complete discussion of this prototype, please refer to the Thesis by Bengt Sahlin, which can be found at the links page.