The End-to-end ATM model

ATM Network Background

• The End-to-end ATM model
• ATM Desktop Model
• ATM Campus Model
• ATM WAN Model
• ATM Carrier Model

ATM Address Format

ATM network addressing is similar to Novell Netware network addressing in that and endsystem has an address with two distinct pieces - a network piece and a local piece. It turns out this is a nice feature especially when analyzing and troubleshooting a network. Since ATM addresses are made up of a network part and a local part, a misbehaving client can be tracked down easily based on its ATM address.

Contrast this to a mis-behaving IP network host. The IP addressing scheme is totally distinct from the local (LAN) addressing scheme -so knowing an IP address is not enough to isolate a misbehaving client in this case (you need to know the local address of the client).

This shows that an ATM address can be represented in a naming format much like an IP address. Note that ATM device names will use the same domain name services (DNS) that IP hosts use - with an extension that maps 20-byte local addresses to a name.

As is the case for IP addresses - there is a process in place for network managers to acquire unique network name and address space. In the case of ATM there are several registration authorities from which one can acquire ATM code points (in the US) - namely, the National Institute of Standards and Technology (NIST) and the American National Standards Institute (ANSI). Basically, ANSI or NIST assigns a 3-octet organization identifier (ORG) code point. This ORG field follows 4 octets of identification bits which identify the country and registration authority (e.g., ANSI). Thus, once an organization obtains and ORG value, the 7 most significant octets of the ATM address uniquely identify the ATM network of that organization. The owning organization is then responsible for the encoding of the remaining 6 octets in the ATM network part of the ATM address. Recall that the least significant 7 octets of the ATM address are locally (client) significant and associated with the ATM client device.

QoS & Speeds

Integrated Services 2

Voice is supported in an ATM network via circuit emulation, via circuit switching, or as data.

Circuit emulation is a migration path supporting emulation of Tl-style WAN circuits. In general many voice circuits are mapped to a single ATM PVC. Voice compression, network echo cancellation, and silence suppression mechanisms may be added as enhancements for bandwidth efficiency.

Optimal support of voice would map traditional 64 kbps voice circuits dynamically to ATM circuits (SVC's).

We also note that voice is supported on IP platforms as data. Some of the same coding, compression, and echo cancellation techniques are applied here as in the circuit emulation case.

Video is supported as realtime, non-realtime, and as data. Realtime video applications include video conferencing and live video broadcasts. Support of realtime video levies strict delay requirements on the ATM network (actually strict delay variation -or jitter - requirements).

Non-realtime video applications such as video-on-demand use application level techniques - namely buffering - to account for inconsistent delays encountered during transit through the ATM network. Thus, the ATM network need not be responsible for ensuring low delay variation requirements (at least not as strictly as in the realtime case.

Video over ATM is a bit more complicated discussion than voice since video terminals are actually audio/visual terminals - that is, voice and video are related and must be kept synchronized.

The illustration above is a simple representation of a broadband (ATM) video terminal (H.310 in ITU jargon).

The idea with supporting data over ATM is that you need a migration path since data applications are tied very much to platforms, operating systems (OS's), application programming interfaces (API's), and protocol stacks (e.g., IP, IPX, Appletalk).

First, software shims are added around low layer API's (close to device drivers - the effect is hiding ATM from existing applications and protocols (users).

Next, low layer and higher layer API's are enhanced to incorporate software shim function and to expose ATM features to existing stacks.

Finally, a new stack and new data applications emerge - all of which are ATM-aware.

Integrated Services

As ATM is the out-growth of broadband ISDN (integrated services digital network), integrated services support was a design consideration from the start. It is worth noting though that many technical compromises were necessary to support three very different network traffic categories. The result of these compromises is that ATM supports the combination of voice, video and data optimally - not necessarily the individual services.

Connection-oriented

Connection-oriented systems (e.g., POTS, ISDN, X.25, TCP, ATM) establish connections between a pair of communicating systems. In the phone system a connection is associated with a physical dedicated link. In ATM, a connection is a virtual link (circuit) which is characterized by a Class of Service which it must deliver to the users of the circuit (e.g., a constant bit rate service for uncompressed voice over ATM).

Connection oriented systems support a set of protocols for transmission of data and another set of protocols for establishing connections (e.g., SS7, Q2931). End systems request that the network establish a connection by sending messages to the network over a pre-defined control channel (circuit). Once the network has established a data channel (circuit) per the request, data is forwarded over that channel. Connections may be established by a network manager as Permanent Virtual Circuits (PVCs) or may be dynamically established by system software as Switched Virtual Circuits (SVCs).