If I get anything wrong, or express a point of view with which you
disagree, please mail me.
As yet, after several years, no-one has complained. That could be because they couldn't be bothered of course.
ATM sounds like it should be the ultimate answer to all broadband networking needs. For the last few years I've been looking into the way it is being used as a networking medium to carry IP and it seems to me that it is totally unsuitable. Despite this, it seems to be the most fashionable way to introduce high-speed links in the UK and Europe.
There are two possible reasons for this.
ATM was never really designed to be a method of tunnelling other network protocols. It was designed as a reliable, high-speed way of ferrying data of different types while providing assured bandwidth and quality of service (QoS).
It's obvious from experience that it does this well. Most of the worlds telephone networks are based on ATM and work wonderfully. However, despite its fitness for this purpose it doesn't necessarily follow that ATM is perfect for all types of data. It also says nothing about its suitability to tunnel other protocols.
TCP/IP networks are generally small, and linked together by routing to form larger networks. The media used is not specified because TCP/IP is not a link layer protocol. Furthermore there is no requirement for the underlying protocols to be the same or even compatible with each other across networks. In practice, local TCP/IP neworks are usually based on LAN protocols such as ethernet, while the links between networks are usually WAN protocols such as Frame Relay or X.25. These days it's common for IP to run directly of SDH/SONET links.
As a result, the most suitable link-layer protocol is used according to the requirements. And everything works well.
Enter ATM. ATM is marketed as the ultimate high-speed reliable system that will revolutionise the internet. But, ATM is not a link-layer protocol, nor is it a network protocol. ATM is both, it covers several layers of the, rather inappropriate, OSI model. Worse still, the link layer cannot be separated from the upper layers. It's all or nothing.
"But", claim the advocates (usually ATM manufacturers), "ATM has many modes of operation. For WAN links you can use CLIP (classical IP over ATM) PVCs (permanent virtual circuits), and for LANs you can use LANE (LAN Emulation)."
LANE is such a hideous abortion of a system I have devoted an entire section to it.
As for PVCs, they work fine (apart from the QoS problem mentioned later). But, what advantages are there in using ATM for a point to point link ? Its very much like SDH only more expensive.
A nice idea. Ideal for controlling QoS and pacing. Voice, video and general data where reliablity isnt necessary, or when retransmits are cheap...
But how many cells are needed to carry just one IP packet ? In most cases several - especially in AAL5. If a single ATM cell gets dropped by a switch, then all of the other cells in the packet need to be re-transmitted. The Policing is supposed to reduce and limit bandwidth, not generate more traffic. Madness.
IP packets are large and therefore a very bad payload for ATM transport. TCP provides the reliability in a virtual circuit, but TCP only knows about retransmitting IP - which means it may cause retransmission of hundreds of ATM cells for each dropped cell.
You can always tell the protocols designed by comittee - they are stuffed to the brim with TLAs (three letter acronyms). Oh yes, they're also generally pretty bad.... dare I mention...OSI ?
To fully understand ATM you need to instantly recognise hundreds of different
acronyms. Most of them all sounding similar enough to confuse the most
dedicated geek.
LEC - Lan emulation client
LES - Lan emulation server
LECS - Multiple LECs ? No! In fact the Lan emulation configuration server.
BUS - something you ride on to work ? A path taken by data ? No, the "Broadcast Unknown server".
Even "ATM" is a bad acronym. "Aysynchronous Transfer Mode", "Automated Teller Machine" or "At the Moment". So you could say "ATM, the ATM is networked to the Banking system over ATM".
Take an ethernet network, make it 10 times more expensive, and 10 times less efficient and you have LANE. Let me give you a brief description of how it works and you will begin to see what a disater it is.
In ethernet, every node has a unique address consisting of a 48-bit number, (the MAC address). For one node to talk to another, it simply waits for its segment to be free and transmits a frame with a header containing the destination address and its own address. This is either broadcast to all stations, or sent to the correct one directly depending on whether you have switched ethernet or not.
In LANE, a client (Lan emulation client, or LEC) not only has a MAC address, but it also has a unique ATM address, which it obtains from a server known as the Lan Emulation Configuration Server (or LECS) each time the LEC is initialised.
When the LEC wishes to talk to another station, it asks the Lan Emulation Server (LES) to establish a Switched Virtual Cirtuit (or SVC) to it. It can then use this to comminucate. However, don't forget that we are actually emulating ethernet here. Ethernet depends heavily on broadcasts and ATM can't broadcast, consequently more appalling kludges are required. Each E-LAN (emulated LAN) has another server known as the "Broadcast Unknown Server" or BUS. It is the job of this server to kludge broadcasts from multicasts and also to provide lookups between MAC addresses and ATM addresses.
An example to illustrate.
One client wishes to send an IP packet to another IP address.
Ethernet
Nuff said..
No longer under construction