An implementation effort may not have to start from scratch. The author of RFC 2022 has made an example implementation, which he provides partly in source code and partly in compiled (object) code for the Sun Solaris platform. A full source license for MARSport can be obtained from Bellcore.
For the implementation on the Linux platform, the code for the ATMARP protocol is the best option to start working on the MARP/MARS implementation. Marko Kiiskilä has done some unfinished work on a MARS implementation on the Linux-ATM platform.
In the LANE implementation, the BUS performs a function similar to the Multicast Server and the code for the BUS implementation may be re-usable in some form for the implementation of the MCS. The current Linux BUS implementation uses point-to-point VCCs to broadcast to the LANE clients, so the problem of the unicast only signalling in Linux is already solved in that code.
The copy service layer is a new concept for the Linux-ATM stack. The implementation of the BUS on Linux, which uses multiple point-to-multipoint VCCs, is probably the closest approximation to the copy service provider. How this service must be integrated into the protocol stack implementation is not clear at this time.
At Bellcore, a complete and portable implementation of the UNI 3.0 and 3.1 signalling specification is available in the form of Q.port. The problem with both this and the MARSport code is that it costs money and it cannot be used for a public implementation under the GNU General Public License.
It is hard to make an estimate of the amount of time required to
implement such a system. If not just the Linux-ATM platform is examined
as an implementation platform, Solaris on a Sun Sparc machine seems a
good alternative. This is, because Solaris/Sparc is a little more advanced and
commercially supported platform. The MARSport software from Bellcore
will be very easy to get up and running, provided the network, i.e. the
ATM-switch, supports point-to-multipoint in the signalling. Leaving
aside the delivery times of required hardware and software
, a
Solaris/Sparc implementation of an RFC 2022 prototype should be possible
in a 2 or 3 months (maybe less).
The linux implementation of a RFC 2022 prototype requires much more time, but it also has merits. If the goal of an implementation project is not just getting a MARS operational quickly to experiment with, but also gain implementation experience of a low-level ATM application, the Linux-ATM platform is very well suited.
An implementation on the Linux platform requires three stages, the duration of which is very much dependent on the experience of the implementor. The first stage is to get to know the existing source code of the ATM driver in the Linux kernel. The second stage is to design an implementation strategy and specification, including the choice of how to solve the problem of the limited point-to-multipoint support in Linux-ATM. The third stage is the implementation itself.
The first stage could take between two and three months, longer if the implementor has little experience with the C programming language .
The second stage is the most difficult, each decision and especially the choice of which multicast method is implemented must be defendable. It could take as much as five months to do this well, because a lot of documentation is needed to form a good understanding of the issues (but this thesis should be able to help).
The third stage is (or should be) just hard work, the academic value of this stage is very minor. Depending on how well the second stage was done and also how fast the implementor can code in the C language, this stage could take four to eight months.