The original problem statement (see Section 1.2) was not specifically meant for the Linux operating system. The reasons why Linux has been chosen are the fact that the full source code is publicly available and that an active base of development on the ATM front is present for Linux. A good alternative would have been Sun's Solaris, because a relatively cheap source license for the kernel can be acquired by universities. A reason to perhaps take another look at Solaris is that the ATM implementations are further developed for the Sun Sparc platform than they are on Linux. The support in the Linux-ATM driver for the Integrated Device Technology Inc.'s low cost NICStAR ATM-25 PCI adapter and the current trend towards Linux were major reasons to chose the Linux-ATM system. The lack of better alternatives at the time of the decision finalised the choice.
In this chapter, an overview will be given of the Linux-ATM driver and how it fits into the Linux networking system. In Section 6.3, a description of the installation procedure and basic operation of the ATM driver is given.
The Linux Operating System (Linux OS) is a free Unix clone with a very
large support base. The complete kernel and practically all
necessary applications to build a complete Unix system are available
for free and in source code under the GNU General Public License
(GPL)
.
The Linux OS is a very open and friendly development environment, because so many people are working on parts of the operating system that it is very likely that someone will be able to assist with a problem that arises in the course of an implementation effort.
Most development on the Linux OS is done by people working in their spare time or in an academic research environment. This may sometimes cause delays in the development that are not foreseen by those who only use the developed code. Technological innovations usually take some time to propagate into the Linux environment, because the specifications are hard to get or cost money ( licenses). Both are serious obstacles to people working in their spare time or in the academic world.
The TCP/IP network interface in Linux is based on the BSD socket API, which is standard on most Unix OSs. This API forms the basis of the ATM Socket API [WA96]. The programming interface for sockets is well documented in several textbooks on network programming [WRS90] and online documents.
The socket interface is a very generic ``virtual connection'' interface. It has several properties, among which the protocol used, data structures specific to that protocol and more.
The following is a quote from the ``Quick And Dirty Primer on BSD Sockets''
The Analogy (or: What is a socket, anyway?)The socket is the BSD method for accomplishing interprocess communication (IPC) . What this means is a socket is used to allow one process to speak to another, very much like the telephone is used to allow one person to speak to another.
In other words, the BSD socket interface provides a means to create an association between source and destination(s) for a specified protocol, interface or other means of communication. Both connectionless and connection oriented data can be sent through a socket.
Without going too much into the details of
Operating Systems Design
[MB86], there are two kinds of environments that software can operate in,
kernel-space and user-space. Kernel-space is a privileged mode of
operation and is used by code compiled into the kernel or loaded as
kernel module after the initial boot process. User-space is for
applications executed by users. These applications can be
daemons,
interactive or batch applications.
Device drivers are always executed in kernel-space, because they need to
access hardware interrupts and other low-level functions not available
in user-space.
Since the beginning of 1995, ATM support is being developed for the Linux OS. The context within which the development is carried out is the ``Web over ATM'' project at the `Laboratoire de Réseaux de Communication' (LRC). The development is open, as is common in the Linux environment, and several people have contributed to the Linux-ATM system in the form of hardware drivers or protocol implementations (e.g. LANE).
The Linux-ATM package is constantly being developed, so the list of
features changes over time as well. What follows is a list of features,
which is kept up-to-date in the README file in the
distribution. This information is for version 0.31 of the Linux-ATM
distribution.
| Type of PIC | PIC make and number | ||||
| 155 Mbit/s |
| ||||
| 25 and 155 Mbit/s | IDT 77901/77903 (``NICStAR'', 77201/77211 SAR) 155 and 25 Mbps adapters (probably also IDT 77914/77915/77916) |
Additionally, a pseudo ATM interface called ``ATM over TCP'' is provided. This interface allows the testing of ATM sockets, without actually having an ATM PIC installed, by encapsulating ATM Cells in a the payload of the TCP PDUs and transporting them over a TCP connection over IP.
The type of signalling used for SVCs is UNI 3.0 or 3.1 is selectable using compiler flags for the signalling daemon (atmsigd).
The following elements of the signalling protocol are not available:
Note that this information is more detailed than is contained in the README file of the 0.31 Linux-ATM distribution. This more specific information was obtained from Richard Jones in response to a question on the Linux-ATM mailing list.
Using direct ATM sockets, two AAL services are available: ``raw'' AAL0 (i.e. raw ATM Cells, without AAL) and raw AAL5 frames over ATM.
Classical IP over ATM using NULL or LLC/SNAP encapsulation is supported. An ATMARP service as defined in RFC 1577 (both client and server) is implemented as well.
A LAN Emulation client and server side (including all modules (LES, LEC LECS and BUS) is provided with the distribution.
Arequipa, Application REQUested IP over ATM, is a protocol to establish an IP ``connection'' between the IP entities on two hosts connected via an ATM network. The connection is set up directly using the ATM destination address, so no complex dynamic ATMARP address resolution process or encapsulation is needed. The service category of the connection and QoS values can be set specifically for the specific requirements of the IP data-stream. The Arequipa protocol is documented in informational RFC 2170.
ANS: ATM Name Service. A service to resolve human readable host names to ATM NSAP addresses.
Supposedly, the Linux signalling entity is capable
of setting up the first leaf of a point-to-multipoint SVC. There is no
support to send ADD_PARTY or DROP_PARTY signalling messages to the
ATM-switch, so only point-to-multipoint VCCs with one leaf can be set up.
This is not very useful for testing multicasting, but it would allow an
implementor to start work on the RFC 2022 entities based on a very primitive
point-to-multipoint VCC support in the signalling.
This is in line with the UNI 3.1 signalling
specification with regard to point-to-multipoint connections
[UNI31, Section 5.6,]. The first SETUP message of a
point-to-multipoint VCC is exactly the same as the SETUP message for a
point-to-point VCC. The difference between the
first leaf of a point-to-multipoint VCC and a point-to-point VCC is that
even with the first SETUP message, state information is passed to the
client and it is supposed to keep that information.
Apparently, the Linux-ATM signalling implementation contains a modification that allows it to terminate a point-to-multipoint VCC as a leaf under certain conditions. The following is said about this by Marko Kiiskilä:
Accepting adding to a leaf in p2mp [point-to-multipoint] works when ATM switch converts add party -messages to setup -messages with an endpoint reference field. Or when the root of p2mp sends setup messages equipped with endpoint reference. Signalling in endpoint needs to be aware of this field (and use it).Support for this endpoint reference -field was added to Linux ATM signalling over a year ago
Thus it is claimed that the termination of an added leaf of a VCC is possible with the Linux signalling entity. This would be useful for a MARS Cluster member implementation (i.e. client side only). Since further state information about point-to-multipoint VCCs is kept in the network and at the called and calling parties of those point-to-multipoint VCCs, this would involve handling the Information Elements for that state information, which are passed along with the signalling messages.
It might be concluded from this that the termination of point-to-multipoint VCCs is somewhat supported.
The hardware chosen for this project is the NICStAR based ATM25 card
from IDT.
The cards have arrived and are now installed in two Linux machines. In the introduction of this chapter, the `low-cost' property was explicitly mentioned as reason for their purchase. This property is reflected in the fact that the cards came without any documentation, driver software or packaging other than an anti-static bag!
The current situation is that there is a kernel (version 2.0.28) with a NICStAR driver from Linux-ATM distribution 0.31, which recognizes the cards. The direct ATM access test-applications aread and awrite work some of the time.
For any communication to be possible, the physical communications layer must be completed by installing the cables between the physical communication entities: the Network Interface Cards (NICs). Three ways of connection are possible with the IDT NICs with UTP cables (This may or may not apply to other NICs using UTP cables). The simplest method is useful for testing only, it uses a `` loop-back'' connector with the operational pins cross-connected (see Figure 6.1). This way, the NIC acts as both ends of a mini network. Compare this with the back-to-back cable in Figure 6.2, where two NICs are connected using a cable. Ordinarily, ATM systems assume a host side is always connected to a switch. In the case of the loop-back or back-to-back connection method, one side of the cable must act as a switch to allow normal protocol operation.
Figure 6.1: IDT loop-back connector configuration
Another, slightly more complex, method is using a `` back-to-back'' connector (see Figure 6.2), which connects two NICs directly without a switch. This method is only useful for experimental setups.
Figure 6.2: IDT back-to-back cable configuration
The third and most ordinary way of connecting the hardware is using an ATM-switch connected to the NICs. Two NICs can communicate with each other using PVCs or SVCs through the switch. SVCs are setup using signalling communication between the NICs and the switch. PVCs are configured manually in the switch. For this method, standard UTP cables (wired straight, without cross-connections) can be used.
In the Linux-ATM protocol stack shown in
Figure 6.3, the logical structure of the ATM extensions is shown with
the existing IP over Ethernet functions. This is a
reference figure, in a real system the available protocols depend on the
installed hardware.
Figure 6.3: Linux-ATM protocol stack reference configuration
This is not the same structure as the modules used to operate Linux-ATM and the sources for the kernel extensions, but it shows how the ATM extensions are integrated into the Linux/BSD socket interface. At the top is the Application, which uses the BSD socket interface to communicate. In this configuration, the application can either choose to open INET (InterNET) sockets or ATM sockets. At a lower level (IP-level) a choice can be made to use either the Ethernet interface or the ATMARP/ CLIP interface for the transmission of the IP packets. The bottom box indicates the device driver (DD) for the PIC installed.
In the running system, the complex protocol functionality is performed in user space by daemons. In the Linux-ATM system the following daemons have been defined (The LANE parts are not mentioned here):
In Figure 6.4 [WA96], the daemons, atmsigd, ilmid and atmarpd are shown with their interfaces to the kernel. The SVC* box is a special SVC socket used to exchange signalling information between the kernel and the daemons.
Figure 6.4: Linux-ATM daemon structure
The kernel maintains an ATMARP table with partial information, which is used to forward packets over existing VCCs and if necessary set up a VCC to known ATM addresses using the atmarpd. The ATMARP daemon also receives IP transmissions, because in the implementation, ATMARP is a layer between the IP layer and the LLC/SNAP encapsulation.
The details of the installation of the ATM driver can be found in the installation manual of the driver distribution [WA96]. In this section, a summary of the operations and some personal experience will be given.
The ATM code from the distribution must be integrated into the kernel. The procedure is described in the USAGE file in the Linux-ATM distribution. When a kernel has been configured and compiled for the installed hardware and usage requirements, the system can be started with ATM support.
Simple ATM transmissions can be done using the aread and awrite commands to send data over a PVC using an [InterfaceNumber.]VPI.VCI combination. The interface number is optional, the default value is zero.
For the explanation of further configuration of the Linux-ATM system, the the following configuration is used: Two Linux-ATM hosts (X and Y) connected to an ATM switch, see Figure 6.5.
Figure 6.5: Example ATM network of two hosts and an ATM switch
To enable signalling, the signalling daemon must be started on the machine using the command ``atmsigd -b''. Now the ATM driver can interact with the signalling entity in the ATM switch. To automatically configure the ATM address, the ILMI daemon must be started by the command ``ilmid -b''.
To show the configured ATM address, the command ``atmaddr -n'' shows the 40 digit hexadecimal number on the screen.
The following commands must be entered on the hosts to install Classical IP and ARP over ATM in the Linux-ATM system. This is for the example network shown in Figure 6.5.
On host X:
``atmarpd -b'' The ATMARP daemon is
started on host X to enable CLIP support.
``ifconfig `atmarp
-c` 10.0.0.1 up'' Now the atm interface (the identifier for the
interface is generated by the ``atmarp -c'' command) is attached
to an IP number, in this case 10.0.0.1.
``route add -net 10.0.0.0'' The IP entity must know that it can
reach network 10.0.0.0 directly.
On host Y:
``atmarpd -b'' See the same command on host X
``ifconfig `atmarp -c` 10.0.0.2 up'' Host Y's atm interface is
configured with IP number 10.0.0.2.
``route add -net 10.0.0.0'' See the same command on host X
Now one host must be configured to act as an ATMARP server for the
subnet 10.0.0.0. (If there is no ATMARP server already available for that
network). We assume that just the two hosts X and Y are connected to the
switch and nothing else. Therefore, one of the two hosts must be ATMARP
server for the other. The default operation of atmarpd is to
act as ATMARP server, so we only need to tell host X that host Y is the
ATMARP server and that it is a client itself. This is done using the command on
host X: ``atmarp -s 10.0.0.0 <ATM(Y)> arpsrv''
Now both hosts are fully configured to act as IP nodes on the subnet 10.0.0.0 over the ATM network. Of course, only unicast transmissions are possible. It should now be possible to use telnet or ftp to contact host Y from host X using IP address 10.0.0.2 using the command: ``telnet 10.0.0.2''.
Once configured, the TCP/IP services offered by the CLIP service are indistinguishable from the ``normal'' Ethernet/IP interface to the user. Indistinguishable apart from the lack of IP multicast support.
The implementations of the protocols used are badly documented, unlike the protocols themselves. This makes it difficult to draw up a model of how the various parts of the ATM driver hang together and how they inter-operate with the existing network system of Linux. In order to ease the learning curve for helping to implement protocol support in the ATM driver, the implementation should be documented in relation to the protocol specification.
One problem which will need a special solution is the lack of adequate support for setting up point-to-multipoint VCCs in the signalling daemon. In the next chapter, some of these ``special'' solutions will be discussed. The use of a non-standard method may influence the inter-operation with other ATM nodes connected to the same network as well. In future versions of the ATM driver, these issues will most likely be resolved. Resolving the lack of point-to-multipoint signalling is perhaps a workable goal for the next project.
In the next chapter, an overview will be given of the modules that must be implemented in addition to the current driver. Also adaptations to the current system and possible sources for re-usable source code are discussed.