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 
. 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 .
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: 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 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 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.