This chapter will give an overview of the required adaptations to the Linux-ATM package to integrate RFC 2022 functionality as described in Chapter 5. Three distinct functionalities can be identified that function independent of each other; the MARS Server, the Multicast Server and MARS Cluster members. These are the entities that require an unique ATM level address, but they can operate on the same physical host. The fundamental problem of the incomplete UNI 3.1 signalling support will be addressed separately.
The MARS Server, Multicast Server and MARS Cluster members can be implemented in independent projects, although they must operate together. In this section they will be discussed separately and under the assumption that a solution has been found to provide some kind of multicast capability in the Linux-ATM protocol stack. In Section 7.2, suggestions for such a solution will be discussed.
Figure 7.1: Separate protocol stacks for the RFC 2022 entities
In Figure 7.1, an overview is given of the protocol stacks for the three entities. The figure is split into two major layers; the generic functionality and the RFC 2022 specific functionality. The generic functionality will be available on all instances using the Linux-ATM stack with IP over ATM capability. The RFC 2022 specific parts only need to run on those hosts that require them. A copy service sublayer could be added to the generic part, to perform the copy service for the multicasting transmission.
First the RFC 2022 specific parts will be discussed, after which the generic parts are explained.
On each MARS Cluster member, an interface must exist to resolve Class D addresses to ATM address lists using a MARS. The ATMARP daemon and kernel extensions currently implemented in the Linux-ATM driver can serve as model for this interface to the MARS.
The current way of handling IP packet transmissions to host group addresses must be modified to add support for multicast address resolution to lists of ATM addresses (instead of into a LAN multicast address).
In the existing CLIP code, the IP entity transmits
through the ATMARP
``table''
in the kernel.
This may well be a good place to start integrating support for IP
multicasting. The ATMARP table in the kernel must be
extended to support (IP multicast address, VPI/VCI combinations).
The clients must support the added field in the LLC/SNAP encapsulation (see Section 7.1.4).
The IGMP functions on the client's side should be
modified to support
direct exchange of membership information with the MARS, instead of
sending IGMP_QUERY messages. This only applies to
implementations in
nodes that function as multicast router. This method of getting membership
information must be implemented in addition to the current ``native
LAN multicast'' oriented IGMP operation. A node may support several
different interfaces at the same time (e.g. combining Ethernet and ATM)
using the same IP stack. Using the device properties, the
implementation can decide which method to use.
Theoretically the MARS-unaware version of IGMP should function as well, but it will cost much overhead on the network and on the host where the mrouter resides (see also [GA96, Section 8.5,]).
The MARS Server implementation is not aware of IP or other layer 3 protocols, it is a direct ATM-client application. It receives queries from clients over VCCs and responds to the clients on those established VCCs. It maintains a ClusterControlVC and optionally a ServerControlVC to send updates on the membership information to the clients and multicast servers respectively. Both ControlVCs are point-to-multipoint VCCs.
It may be possible to implement the MARS and MARP services in one daemon, like the ATMARP daemon. In that case the current code for the ATMARP daemon may be used as a basis for the Multicast Address Resolution Protocol. Since ARP and MARP are similar in that they both use a server to resolve addresses on ATM, a combined implementation is worth looking into.
As mentioned in Section 5.2.2, two kinds of MCS implementations
exist; a generic, but ``dumb'', MCS instance for each host group or a
single ``smart'' MCS with some knowledge of layer 3 headers (IP in this
case) for multiple host groups.
With the ``dumb'' MCS, a unique ATM
address must be used for each MCS instance. Multiple MCSs can reside on
one machine if the SELector byte of the ATM address is used with an
otherwise equal NSAP address.
The ``smart'' MCS will have to do some processing of each AAL5 frame, which may cost much time and thus, delays in the transmission.
At this time, it is hard to say whether the performance of the MCS will suffer significantly because of the layer 3 header processing overhead. If the complexity of the MCS is not too great, it would be interesting to experiment with both types of MCSs and measure the performance impact.
To comply with RFC 2022, a MARS client must support the extended encapsulation scheme specified in Section 5.5 of RFC 2022. The extended scheme supports two types of encapsulation, called Type #1 and Type #2. Clients that comply with the specification in RFC 2022 must support the receipt of both types, but they may only use Type #1 for sending. Type #2 is reserved for future use, when the number of MARS Cluster members exceeds the capacity of the 16 bits Cluster Member Identifier (CMI). E.g. when the specification is extended to support direct ATM level multicasting outside the cluster boundaries.
The receiving part of the LLC/SNAP encapsulation implementation must recognize and discard reflected multicast transmissions from a MCS.
The copy service layer as shown in Figure 7.1 is a way to hide the lack of support for point-to-multipoint signalling in the Linux-ATM implementation. It will be explained as a solution to that problem in Section 7.2.1 and compared to implementing the copy functionality in the MARS and MCS entities.
In Chapter 4, the combination of signalling, AAL and ATM Transport services were named: ATM Bearer Services. In Linux-ATM, a subset of the complete ATM Bearer Services has been implemented. Only limited UNI 3.1 and UNI 3.0 signalling support is implemented (see Chapter 6) and only one real AAL layer is provided (AAL5). The lack of VBR and ABR service categories is not a serious problem and neither is the lack of support for other AAL types than AAL5. The lack of point-to-multipoint signalling in the UNI 3.x specification is a serious problem and will be addressed in sections 7.2 and 7.2.2.
In the Linux-ATM implementation, a solution must be found to provide a multicast service in or directly on top of the ATM bearer service provider. If the current signalling implementation is too difficult to modify in the time of one project, a solution must be found on another level. First a ``virtual multicast service'' will be discussed, which operates on top of the point-to-point connections of the ATM Bearer Service. After that, the feasibility of adding signalling support for point-to-multipoint VCCs to the ATM signalling entity is discussed.
Four options exist to create a copy service for multicast transmissions in the Linux-ATM system. The options are shown in Figure 7.2. The best way is, of course, to implement point-to-multipoint support in the UNI 3.1 signalling entity. This option will be discussed separately in Section 7.2.2. If the extension of the UNI 3.1 signalling support is not chosen, a way must be found to perform the copy service.
This can be done before or after the IP packets are encapsulated using the LLC/SNAP encapsulation. Alternatively, the lower parts of the Linux-ATM stack can be completely left alone by implementing the copy service only in the MARS and MCS entities.
Figure 7.2: Implementation options for the Copy Service in Linux-ATM
The copy service (or virtual multicast service) would make it appear as if the ATM socket service provider supports point-to-multipoint VCCs. In reality, the entity that implements this virtual multicast service should copy the incoming data and send a copy to each recipient over a point-to-point VCC. To higher layers, this entity might appear similar to how point-to-point SVCs would be approached. Such an implementation would work like the service shown in Figure 3.2 B.
Starting from the bottom up, performing the copy process after the encapsulation and just before the transmission over ATM VCCs is the most general and lowest level possible for such a function. This option would not only cost little processing overhead (the encapsulation is already done), it might also be easier to do the copying at a lower protocol level. Before a choice is made between this alternative and the next, a list of pros and cons should be made to compare the two.
If data is copied before the LLC/SNAP encapsulation is performed, the copy process needs to be done for all recipients. Since the encapsulation is done in software, this causes extra processing time on the sending host. For the implementation, it would most likely also mean a completely different source file to implement the copying in than when it is done after encapsulation.
In a ``normal'' RFC 2022 implementation, a sending MARS cluster member can use either a VC-mesh or a MCS to perform the copying and forwarding of the multicast data. This is determined by the configuration of the host groups in the MARS; if a MCS is configured for a group, the ATM address of the MCS will be provided to the clients when they try to resolve the IP host group address.
This control in the MARS over how the clients do their multicasting can be used to force the clients to use a MCS. The ability of the current Linux-ATM signalling implementation to set up the first leaf of a point-to-multipoint VCC, can be used to allow completely standard operation in the clients when they send to the MCS for further transmission of the multicast data.
If no full point-to-multipoint support is operational yet, the MARS and MCS entities can use multiple point-to-point (or single leaf point-to-multipoint) VCCs to copy their multicast transmissions and forward each copy over such an unicast VCC. The MCS and MARS entities will function like the protocol entities shown in Figure 3.2 C.
Internally, an implementation must be able to identify virtual point-to-multipoint connections, both before and after they have been established. If a virtual VPI/VCI combination is used to identify a virtual point-to-multipoint connection, the copy service must keep an administration of which established point-to-point VCCs are associated with it. This would limit the number of multicast VCCs that can be used and also break the current range of allowed VPI and VCI values. This could be solved by allowing the internal values of the VPI/VCI fields to be greater than the ATM specification dictates. Obviously, this is a temporary solution, but when used only for internal administration purposes, there is little harm in it, if it facilitates a quicker implementation.
An alternative to this method is to use lists of ATM addresses to identify a group of VCCs for a multicast transmission. This would be less complex for the implementation of the copy service and more like the interface would be with the signalling entity if it would support setting up point-to-multipoint connections.
Both solutions differ from the way an implementation based on real point-to-multipoint VCCs would work. Such an implementation would have two different stages of addressing; first a list of ATM addresses is used to set up a point-to-multipoint VCC and then the resulting VPI/VCI combination is used by the entity that has to send to the host group.
The implementation of a copy service may not be trivial and it is perhaps not worth investigating this temporary solution. UNI 4.0 support will be added to the Linux-ATM driver at some time and it is worth looking into helping with its implementation. UNI 4.0 support may not be available in the short term and it is not unrealistic to assume that currently operational ATM switches lack support for UNI 4.0. UNI 3.1 point-to-multipoint VCC support may be a more attainable goal and provide a more usable system.
The current implementation of the signalling entity in the Linux-ATM system supports a subset of the UNI 3.1 signalling specification [UNI31]. Native ATM multicast (or point-to-multipoint VCC) signalling support is essential for a complete implementation of the proposed IP multicast support of RFC 2022.
UNI 4.0 signalling support is high on the list of things to be added to the Linux-ATM package. UNI 4.0 signalling includes support for point-to-multipoint VCCs, Leaf-Initiated Joins and Leaves and Anycast addressing for point-to-point VCCs.
Extending the current signalling capabilities with support for point-to-multipoint connections is an option that is worth considering. However, it requires extensive knowledge of the ATM signalling protocols and facilities to test the correctness of the implementation. Section 5.6 of the UNI 3.1 specification [UNI31] is where the signalling messages for point-to-multipoint connections are defined. The sources for the signalling entity in the Linux-ATM package already contain the definitions of all the UNI 3.x signalling messages, but the protocol handling functions are not implemented.
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.
As already mentioned, the Linux-ATM driver is constantly being
developed. Currently the primary focus is on integrating the driver
into the development version (2.1.x) of the next major upgrade of the
Linux kernel (2.2.x).
The next stable version of the kernel will, among other things, have support for IPv6 and structural changes to name resolution and NFS. It is the intention of the developers of Linux-ATM to integrate ATM into the new kernel as well as improve and stabilise the functionality of the driver.
Several people are developing drivers for hardware. This will make Linux-ATM more popular and thus increase the speed of other developments of the Linux-ATM system.
With the integration of the driver into the new kernel version in mind, some people are thinking about how to support IPv6, which will form an integral part of the new Linux kernel, on top of ATM. Unlike IPv4, there is currently no IETF RFC to guide this development yet. As mentioned before, there is work in progress in this area though.
Implementing multicasting support in the current Linux-ATM driver involves a lot of changes and great knowledge of the driver's internals as well as an understanding of the ATM and IP specifications. An estimation of the amount of time required to form a basic understanding of these matters, enough to implement a working system, is between two and four months.
For an implementation of the RFC 2022 specification in the Linux-ATM system, several choices have to be made: Whether to wait for functionality to become available, to implement that functionality properly in the signalling entity or to add it using a temporary solution. Although it may take longer to get results, implementing point-to-multipoint VCC support in the signalling entity to comply with the RFC 2022 specification, would seem the best way to get a result that can be used in the long term.
The implementation of RFC 2022 within the current IP over ATM system
will cost much time. The time to implement the complete
functionality of a RFC 2022 compliant system is probably about one to two
years (for a single person). If only a part of the functionality is
implemented, it would still take a long time to get to know the
Linux-ATM system and the protocols involved. A minimum of six months for
an implementation of just one module of the RFC 2022 specification
seems reasonable, including the time it takes to get to know the
protocols and sources. The time to develop the implementation could be
shortened by having several persons work on the different modules in
close cooperation. The sharing of experiences with working with the
Linux-ATM code between them would shorten the learning curve.
The addition of point-to-multipoint support to the signalling entity may not be very hard to do, considering the current state of the signalling implementation, see Section 6.2.2. For a more precise evaluation of the time required to make the necessary modifications mentioned in this chapter, more digging into the source code is required.