Asynchronous Transfer Mode

Integrated Services Data Network

if each telephone line can carry 64Kb/s
and there are two telephone lines (4 wires) into each home,
the telephone company can provide 128Kb/s line to every home: ISDN
overpriced, never took off in the user market: not much software, required a telephone company ISDN "modem", little ISP support

most lines are higher quality than the telephone requires
therefore on most lines we could send a lot more than 128Kb/s
up to maybe 5,000 feet (maybe 80% of homes) can send 1Mb/s with low error rate: DSL
further improvement: make uploads (transfers into the home) faster, don't worry as much about download speeds

ATM designed in the late 80s and early 90s to carry both synchronous (voice) and asynchronous (data) traffic
connection-oriented transfer of fixed-size cells
connection establishment is used to negotiate parameters of call
cells can be, but don't have to be, sent on a periodic basis
fixed size of cells makes hardware switching feasible/cheaper
permanent and switched virtual circuits

a host connected to an ATM network requests a connection (makes a call) to another host before data can be exchanged
the connected ATM switch must route the call towards its destination
confirmation that the call has gotten through leads the switch to allocate resources:
- virtual circuit identifiers
- space in the (hardware) forwarding table
- bandwidth, queue space
the switch then responds to the caller, specifying the virtual circuit identifier
virtual circuit identifiers are local to a single link

company X at locations A, B connected via ATM
ATM switch at A would establish a Virtual Path (VP) to ATM switch at B
switches between A and B carry all cells with the same VPI, ignoring the VCI (so the VCI will remain the same from A to B)
signaling for establishing virtual channels between hosts at A and B need not involve intermediate switches
at switches A and B, cells from the virtual path are routed based on the VCI

on receipt of a 53-byte cell:
check the header CRC, perhaps correcting single-bit errors (discard if more errors)
look up VPI, VCI in hardware memory: may ignore VCI depending on setup, must discard channel ID is not valid
lookup yields outgoing: interface, VPI, VCI
insert new VPI, VCI in cell
queue packet on outgoing port, possibly setting the congestion indicator and discarding if the queue is full enough and CLP=1
compute header CRC and send

connection-oriented network
all routing done at connection setup time
priorities and support for real-time
fixed-size cells, bigger Packet Data Units (PDUs) handled by the ATM Adaptation Layer (AAL, especially AAL-5)
20-byte addresses, capable of containing a telephone number

no need to send a byte 8,000 times per second
more complicated because of the need to accomodate data traffic
data could be treated as "second class", but there is real-time compressed (variable bandwidth) data
large data layer (AAL1, AAL2, AAL3/4, AAL5, signaling, Information Elements)
big emphasis on quality (CRCs, etc)
easy multicast

single sender, millions of receivers "tuning in"
any centralized "add" is unwieldy: for example source-based, server-based
leaf-initiated join is best
ideally, in a leaf-initiated join, join request only proceeds until it reaches a switch already carrying the signal
switch hardware must support multicast:
- multiple output ports
- possibly, multiple output VPIs/VCIs
with leaf-initiated join, never need to forward the same cell to the same port multiple times

Comparison of sender-initiated join and leaf-initiated join: