The reader is probably familiar with the Internet, the global computer network everybody nowadays uses to communicate with people all over the world and look up information using the World Wide Web. Less well known is how exactly this Internet works. Fortunately it is not necessary to understand the complex workings to be able to use it. Since the start of the popularization of the Internet (when WWW was invented in 1993), more and more applications of the Internet use graphics, audio and video to enhance the content of the communication. One application that is predicted to grow fast in popularity is multiuser conferencing using audio and video. A serious problem with that kind of application is the bandwidth requirements of real-time interactive audio and video. With just two users communicating, this is already a heavy load for a common Ethernet network. When the video is not transmitted to one user, but to several, the bandwidth requirements increase linearly with each additional user....or doesn't it?
One way to solve the problem of bandwidth shortage is to provide more. Several new network technologies exist that can provide ten times (and more) bandwidth than those currently used. One of them is Asynchronous Transfer Mode (ATM). ATM can use different types of media and can be scaled very well to handle a wide range of bandwidths (from 1 Mbit/s to 10 Gbit/s or higher). One problem with ATM is that it is still in the process of being defined.
But is adding more bandwidth enough? Applications like pay-TV, where only paying viewers can watch, typically have not 10 or 100 viewers, but more like 100,000 or even millions of viewers. Clearly, adding bandwidth is not a realistic solution, it would only solve small scale multi-user problems.
A more scalable solution is ``Multicasting'', a service provided by the network to copy the data you want to transmit to each user that wants to receive it. The network will copy the data only when two destinations cannot be reached over the same link, which makes it a very elegant solution that ideally uses no more bandwidth than a single transmission on each network it needs to be.
For the Internet the first steps to add multicasting support to the existing set of protocols were made as early as December 1985, when the first official document (called a Request For Comment or RFC) was published: ``Host Groups: A Multicast Extension to the Internet Protocol'' (RFC 966).
ATM and multicasting together combines high bandwidth with efficient transmission to multiple destinations. When the Internet factor is integrated as well, high bandwidth multimedia conferencing over the worldwide Internet should become a reality. The prospect of multicasting to millions of viewers is a lot less daunting than sending each user a separate copy from the source.
Given that ATM has support for unidirectional multicast connections, the implementation of IP multicasting over ATM seems a relatively easy step. However, several complications with such an implementation can be identified and need to be addressed.
The department of Computer Science at the
University of Twente is investigating the possibilities of using
ATM in a production
environment
.
This would replace current Ethernet-based systems,
which are mainly used for applications using the
Internet Protocol, but also some broadcast
oriented services (e.g. remote uptime, remote users,
Address Resolution Protocol (ARP) and
Network Information Service (NIS)).
Both LAN Emulation [AFLE95] and
Classical IP and ARP over ATM (RFC
1577, [ML94]) are considered. The problem is that simply using
existing Classical IP and ARP over ATM is not enough, because no
broadcast/multicast services are provided. The question is whether
adding support for multicasting to Classical IP over ATM is feasible
and if so, whether it will be faster and more efficient than IP over
LANE.
From this context, my problem statement was created:
The goal of this thesis is to find a way to add a multicasting capability to the existing Classical IP and ARP over ATM service described in RFC 1577. Several issues need to be investigated in this context:
'Support for Multicast over UNI 3.0/3.1 based ATM
Networks'.
In the course of this project more insight has been gained into the problems associated with IP multicasting over ATM. From this insight a rephrased problem statement will give a better overview of the work required to implement a such a system.
The problem stated above is too much work for a single person in the time associated with this kind of project, but it would guide an effort more directly towards an implementation of the IP multicasting over ATM system.
After the introduction and background explained in this chapter, in Chapter 2 a basic method of network description will be discussed, using the Internet Protocol (IP) as an example. The focus in Chapter 2 will be towards an implementation architecture that can be used later to formulate the IP multicasting over ATM system in. In Chapter 3, an overview of multicasting in general will be given and IP multicasting will be discussed in detail. In Chapter 4 an introduction to the basics of Asynchronous Transfer Mode (ATM) will be given. In the same chapter, Local Area Network Emulation (LANE) and Classical IP and ARP over ATM (CLIP) are introduced. In Chapter 5, the IETF document RFC 2022, 'Support for Multicast over UNI 3.0/3.1 based ATM Networks', will be reviewed.
The previous chapters are a generic survey of the protocols and specifications required for an IP multicasting over ATM system. The next three chapters will be specific to the Linux-ATM platform, which has been chosen for this project. Should another platform be chosen for a followup project, the previous chapters hold their value, only the platform specific parts must be re-investigated.
In Chapter 6, the Linux-ATM package will be reviewed. In Chapter 7 the modifications to the Linux-ATM implementation, required to create a fully operational IP multicasting over ATM implementation are specified. The conclusions reached in this project and the recommendations for further work are presented in Chapter 8.
This thesis is laced with references to both paper and
electronic documents on this subject. Since this thesis gives an overview
of the protocols, the reader is
referred to the references for a complete specification of the protocols
used.