Asynchronous Transfer Mode ATM (part 2)

This lecture is divided into hyperlinked sections

Introduction
ATM Interfaces
ATM Cell Header
Transporting Cells
Traffic Parameters
The Traffic Contract
Addressing in ATM Networks
Signaling
ATM Signaling Functions
Route Calculation
ATM Routing Protocols
ATM Architecture
Physical Layer Types
ATM Layer
ATM Adaptation Layer
AAL 1
AAL 2
AAL 3/ 4
AAL 5
Comparison of AAL 5 against AAL 3/ 4
Summary


Introduction

This lecture will examine ATM cell headers
We will look at cell switching
Traffic Parameters and the Traffic Contract will be examined
We will examine ATM addressing and routing
We will see the ATM architecture and the Adaptation Layers


ATM Interfaces

ATM defines several interfaces in order to promote interoperability. The two most common interfaces are the User to Network Interface, UNI and Network to Network Interface NNI. Each of these interfaces may be either private or public, depending on the actual equipment that is being connected.

 

Figure 8.1  Diagram depicting Various ATM Network Interfaces


ATM Cell Header

The header of ATM cells follows the same 5 byte format. The first bits of the cell are treated differently at NNIs and UNIs. The header of a UNI cell contains a 3 bit field, the GFC field which is not yet used although its future use is intended to be as a multiplex identifier at the user's terminal. NNI cell headers do not have a GFC field.

There then follow fields to contain both the virtual path identifier and the virtual channel identifier. Within the network, these identifiers are used to route the cells toward their destination along a previously defined path of hops. At each hop of the network, connection lookup tables exist to route the cells. The VPI and VCI are not global variables. They are generated locally at each hop and change for each hop.

 
 

The PTI Payload Type Identifier field consists of three sections of one bit each:

· Type is set to one, it is a User cell. If Type is set to zero, it is a Network cell.
· EFCI is Explicit Forward Congestion Indication, a bit which is set to one when a cell has experienced congestion at a network switch. This will inform the receiving entity of congestion along the route the cell has travelled and may be used to slow the transmission of the receiving entity cells in an effort to ease the congestion.
· The User field is currently carried end to end without change.

CLP is cell loss priority and is one bit to indicate the priority of delivery of the cell. 0 is set for normal priority and 1 is set for low priority. If a switch is experiencing severe congestion it may drop lower priority cells in an attempt to avoid total collapse and loss of much data.

HEC header error check is used to check the validity of the header only. Error checking of the payload is carried out at either end by higher layers. HEC uses CRC and will detect virtually all multi-bit errors as well as having the ability to correct single bit errors. There is a high probability that a cell with a damaged header will contain incorrect virtual channel or path data therefore if it is relayed upon an incorrect path it may arrive at the wrong destination. Otherwise it may reach the correct destination, but be of no use. Thus damaged cells are discarded rather than being forwarded for the reasons outlined above. The HEC field is also used to help delineate the cell boundary between header and payload.
Cell Switching

This takes place at the core of the network whenever streams of cells arrive at a switch. The cells arrive at the input ports of the switch and must be connected to the correct corresponding output port to continue their journey to their final destination.

Within the cell header is the VPI number. A cell cannot retain the same VPI number across the network because this would mean that all switching nodes globally would have to know all the VPIs in use at any instant, an impossible task. Thus the VPIs are assigned locally for each hop across the network to the next switch and only have local significance between switched ports. This allows for only a small set of numbers to be allocated for VP numbers. Note the VC number remains unchanged.

To accomplish the switching, each input port in the router has its own routing table. Each output port has its own translation table. The routing table maps the incoming VPI to its corresponding output port and the translation table maps the incoming VPI number to its corresponding outgoing VPI number.

Sets of separate cell streams arrive at input ports on the switch. Each input port examines the header of each arriving cell and acts upon the data held within the header. If the HEC is in error the cell is discarded, else the output port of the switch for the VPI number (to which the cell must be routed) is looked up from the routing table for that particular input port. The cell is switched to the appropriate output port buffer and if the VPI number indicates that the cell is multicast, it may be copied to the output buffer of other ports too.

The new outgoing VPI number is looked up from the outgoing port's translation table and now the cell header must be revised. The new VPI number is written into the header and the EFCI bit may be set if the switch is experiencing severe congestion. The new HEC byte is calculated and loaded into the header.

This cell will be transmitted when the scheduler allows according to the CLP bit which is set to indicate low cell priority i.e. the cell is part of a bursty stream that will be unaffected by a little more delay or is it. If the bit is not set then the cell is part of an isochronous stream and should be delayed as little as possible.
 

Figure 8.3  ATM Cell Virtual Path Switching

The method of switching virtual paths increases the switching efficiency because switching a VP routes all VCs in that VP at once.

If it is necessary to switch individual channels then the virtual path will need to be terminated. This is accomplished using a virtual channel switch. Here the virtual path is terminated and the cells are routed by processing the VPI and the VCI. New VPI and VCI are written into the cell header.


Fig 8.4 VP Switching

Note in the figure above that the VC number remains the same either side of the switch. The cells marked as 0/0 are empty. Contrast this with VP/ VC switching where both the VPI and VCI are used and are different either side of the switch.


Fig 8.5 VC Switching

Whilst each individual input port does its own processing and has its own input buffer, the output buffer for all the ports is often shared. Part of controlling the switch fabric are management services to provide route calculation, memory allocation and congestion control management.


Transporting Cells

The ATM forum has defined five separate categories of service CoS for cell transport. These categories define the transport service that users should be able to receive from the network. Users should seek suppliers who provide all five categories.

Every VCC has a CoS associated with it and the CoS is assigned when the VCC is connected. The CoS allows users to inform the supplier of their data traffic requirements. The user only has knowledge of these assignments. For instance:

· Isochronous voice or video requires little or no delay
· Database synchronisation or imaging requires very few errors
· E-mail benefits from cheap service as it can withstand delays.

CoS support is essential to allow ATM to meet its delivery promises.

Table 8.1  ATM Categories of Service

There are also three Quality of Service, QoS parameters that define user performance requirements on a VCC. The QoS can be negotiated between the user and the network when the VCC is connected. Currently it is common practice to use the default QoS.


Table 8.2  ATM Qualities of Service

For example, a CBR VCC with CTD = 10 ms
           CDV = +/- 1 ms
           CLR = 10-9 (one in a billion lost)


Traffic Parameters

When the VCC is set up, the user provides the network with information concerning the traffic that it intends to send through the network. Four traffic parameters are defined and these categories vary with the requested service category.

Table 8.3  ATM Traffic Parameters


The Traffic Contract

The traffic contract is defined by the CoS, QoS and the traffic parameters and this information is exchanged between the user and the network at initialisation of the VCC. If the VCC is accepted by the network, this means that the network has guaranteed the nature of the VCC and the user has committed himself to send the expected traffic on the VCC. If the network cannot fulfil its guarantees, the VCC must be denied. Note that each VCC has its own independent traffic contract. The table below shows various different traffic contracts.

Table 8.4  Examples of possible ATM Traffic Contracts.


Addressing in ATM Networks

All networks including ATM require addressing for each end system. ATM addresses combine the characteristics of traditional LAN and WAN addressing schemes.

LAN addresses are 6 bytes and IEEE administered. They also have supplier significance.

WAN addresses (E.164) can be up to 15 digits long (8 bytes) and are ITU-T administered. They contain information concerning the location of the system.

The ATM Forum specifies that a private ATM address will have two parts.

1. A 6 byte end system identifier ESI which is essentially an IEEE LAN hardware address.
2. An up-to 10 byte network prefix which is 'inherited' from the location of the system within the network and is essentially the location of the attached switch.

Figure 8.6  Depiction of ATM Network Addressing

Private network addresses will be encapsulated into an ITU-NSAP and will be 20 bytes long. There are two format choices and they are distinguished by the Authority and Format Indicator AFI which contains either the Data Country Code, DCC or International Code Designator. Private networks may use E.164 addresses obtained from the ATM Forum. These take the place of the Network Prefix.


Figure 8.7  Addressing in ATM Networks



 
Signaling

Signaling is used to transfer service-related information from the user's station to the network and also between switches in the network. Signaling is carried out within the ATM network by the transfer of signaling cells having a VPI of zero.

Currently (Aug 99) signaling standards in ATM are incomplete and much work remains to be done.

· At the UNI, the signaling standard is Q.2931 based upon ISDN Q.931
· At the private NNI, there is Interim Interswitch Signaling Protocol IISP
· At the public NNI, signaling is based upon Signaling System 7 SS7 with extensions


ATM Signaling Functions

The signaling exists to exchange information between the nodes of the ATM network. Virtual circuits are set up and released and routing information for VPIs and VCIs must be assigned and stored.

The switches learn the topology of the network and keep a record of the physical connections between the switches and the addresses of attached terminals.

Changes in the topology of the network are automatically adjusted for:

· Alternate information paths can be established if this becomes necessary
· Failed or congested switches can be bypassed
· Terminals that have been disconnected and reconnected elsewhere are rediscovered

All the above should be carried out within a few milliseconds although this is currently being worked upon.

Another signaling function is Operations, Administration, Management and Provision OAMP which deals with queries, control instructions and configuration commands etc.
 
Figure 8.8  Setup of Switched Virtual Channel

Signaling is used to set up the calls or bidirectional SVCs before they can be used. The source end user starts to send setup cells to the network, in the figure above using VCI = 5. The cell also includes traffic information and destination.

The Network then determines:

· Whether resources are available to meet the request
· How best to connect the SVC
· The VCI/ VPI to be used
· Whether the destination is there or willing to receive the call

If all of the above can be satisfied, a cell is returned containing a connect message and the SVC can be used.

Signaling may also be used to change call parameters such as adding or removing destination stations.

Signaling is also used to release or teardown an SVC after use.


Route Calculation

ATM networks require some sort of network route calculation service to determine the path through the network when connecting VCCs. These paths may differ for other traffic contracts.

Route calculation requires:

· A knowledge of the network topology with
· Location of end systems
· NNI trunks
· UNI and NNI bandwidths
· Knowledge of the traffic contract requested by the user
· Optimum paths may differ for different traffic contracts
· Knowledge of the PVCs and SVCs already connected

The route calculation service is usually provided by dedicated processing (both soft and hardware) located in the ATM switch chassis. It is a challenge to ensure that this distributed multiprocessor environment functions as a whole. The closest model that we currently have is routers and routing protocols e.g. RIP, OSPF, NHRP etc.


Figure 8.9  Example of an ATM LAN switch


ATM Routing Protocols

Currently there are three types of ATM routing protocols available.

1. Proprietary Protocols. Here switch manufacturers supply custom software (e.g. Fore Systems SPANS). Multivendor interoperability is not possible.
2. Interim Interswitch Signaling Protocol IISP. This is an ATM Forum specification and has been available since early 1995 with the goal of multivendor routing. Switches use IISP signaling to exchange VCC hop information. Each switch maintains a static next-hop routing table. Network personnel must update these tables, but supplier support is not widespread.
3. Private NNI (PNNI) protocol from the ATM Forum. ATM Forum PNNI v1.0 specification has been available since mid 1997. Its goals include complete routing support for dynamic environments, support for all Qos and CoS and multivendor interoperability. It is a very complex, dynamic self-learning protocol that is loosely based on IETF's OSPF routing protocol. Supplier support is gradually increasing but this calls for substantial processing power, available on the newest switches. It is not generally available as an upgrade to existing switches.


ATM Architecture


Figure 8.10  Simplified ATM Reference Model

The physical layer functions PHY are divided between two sublayers that receive and deliver cells to and from the ATM layer.

The Transmission Convergence Sublayer TCS adapts cells to and from the transmission medium effectively decoupling the data rate of the network equipment and cable. For some PHYs, TCS maps multiple cells into transmission packages. It also deals with the HEC, correcting all single bit errors and discarding damaged cells and is responsible for cell header delineation.

The Physical Medium Dependant PMD Sublayer transmits and receives the bits to and from the cable. It specifies the cable type, connectors, data rates, timing, power budgets etc. 


Physical Layer Types

The ATM physical layers are SONET/ SDH based and are the choice for WAN and MANs. The cells are inserted into the payload of a SONET/ SDH frame. A SONET/ SDH STS-3c/STM-1 data container (a 125 ms time slot) can carry a total of 155.52 Mbit/sec with 148.76 Mbit/sec of payload or 353208 cells per second.

The choice for LAN is usually cell based with cells being transmitted constantly and no additional framing.

Another choice is Framed where cells are inserted into a framed structure, e.g. DS-3.

There are many different physical options available for ATM transport and this provides for deployment flexibility and migration options.

Table 8.4  Table of Physical Layers Specified for use with ATM


ATM Layer

The ATM layer is independent of the physical layer. The ATM layer is responsible for encoding and decoding the header fields of the cells. This includes cell routing responsibility with VPI and VCI extraction and translation and control of routing tables.

The ATM layer takes 48 byte chunks of payload handed down from the ATM Adaptation Layer AAL, and checks for the appropriate VPI and VCI from tables that it carries. The VPI and VCI are entered in the header and the header is attached to the payload. The complete cell is passed down to the physical layer for transmission onto the cable.


ATM Adaptation Layer

The function of the AAL is to groom various data flows so that they can be passed to the ATM layer in appropriate 48 byte segments. Five AAL types have been defined, but one of these AAL0 (Null AAL) has been reserved for future use when applications have been tailored to produce 48 byte segments of output data to suit ATM. These types are summarised below.

AAL 0 For future use when applications produce 48 byte payloads
AAL 1 Designed for CBR, isochronous traffic, voice, video
AAL2 Under study for VBR, isochronous traffic e.g. MPEG-2, HDTV. It should carry data and timing information and indicate unrecoverable errors
AAL 3/ 4 This was developed by the telecom community for bursty packet traffic and can be connection oriented or connectionless
AAL 5 This was added by the datacom community for packet based traffic and is considered better than AAL 3/ 4 for LAN needs

AALs are very complex because they manage to adapt many different types of signals to the ATM cell format. The AAL receives user data from the upper layers and then processes the data in the convergence sublayer. The data is then segmented into 48 byte chunks in the Segmentation and Reassembly SAR Sublayer


Figure 8.11  Functions of the ATM Adaptation Layer


AAL 1

AAL 1 is for constant-bit-rate CBR isochronous data. The major functions of the AAL 1 Convergence Sublayer CS are to:

Transfer CBR data to and from the ATM layer at the same bit rate
Transfer timing information from source to destination to enable correct interpretation
To recover form errors and indicate unrecoverable errors

Exact details of how these functions are to be carried out is still under discussion.

AAL 1 Segmentation and Reassembly Sublayer SAR takes an input of 47 bytes from the convergence sublayer. Thus SAR data units carry 47 bytes. A 1 byte segmentation and reassembly SAR header is prepended to the SAR data unit.

The SAR header consists of 3 sections:

I A 1 bit convergence indication that can provide time stamps in the payload
SN being a 3 bit sequence number SN
SNP a 4 bit field carrying Sequence Number Protection using CRC-3 and parity



 
AAL 2

AAL 2 is intended for VBR isochronous traffic with some audio and video compressors producing this type of traffic. MPEG-2 and HDTV are examples of this. MPEG-2 can be characterised by being bursty traffic with local maxima.
The specifications for AAL 2 are incomplete. 


AAL 3/ 4

AAL 3/ 4 takes packets of user data from higher layers and prepends this with a 4 byte Convergence Header and appends it with a 4 byte Convergence Trailer. The user data can be up to 64 Kb or 65535 bytes. This is passed from the Convergence sublayer to the SAR sublayer and is broken into 44 byte segments with padding added if necessary to make the last cell contain 48 bytes. A two byte header is prepended and a 2 byte trailer is appended, making 48 bytes. The cells can then be passed to the ATM layer.

Figure 8.12  AAL 3/ 4

The extra information carried in the headers and trailers is to ensure correct reassembly of the original packet at the receiving end.

AAL 3/ 4 resulted from the merging of the work of two asynchronous AALs standards committees that were assigned early in ATM development. AAL 3 was defined for connection oriented services, examples being X.25 and frame relay.

AAL 4 was designed for connectionless service and examples are SMDS and IP.

AAL 3/ 4 adapts asynchronous packet-data streams for ATM transport and these packets can be up to 64 Kb i.e. 65335 bytes.

Unfortunately AAL 3/ 4 is considered to have too high overhead and this led to the development of AAL 5 putting the future of AAL 3/ 4 in doubt.


AAL 5


Figure 8.13  Operation details of AAL 5

AAL 5 is the simplest of all the ATM Adaptation layers and is sometimes referred to as SEAL (Simple and Efficient Adaptation Layer) and also 'skinny AAL.'

It is intended for the LAN market for high performance workstation LANs and also LAN backbones.

The data packets that are fed down to AAL 5 can be TCP/IP or X.25 which are then encapsulated by AAL 5. AAL 5 is more efficient than AAL 3/ 4 as all 48 bytes of the cell payload are used for data except for the last cell in the series.

One cell header field is used to indicate the last cell of a series. The last bit in the payload type PT field is used with PT = 0 indicating that more cells are following,  PT = 1 indicating the last cell of the series.

The last cell also carries Convergence Trailer information.

· U (User To User Indication) and C (Common Part Indicator) bytes are currently under discussion.
· Len (Length) is a two byte field that carries the length of the data packet (max = 65535 bytes)
· CRC-32 is a 4 byte error control number that is identical to that used in FDDI. This is computed for the entire convergence sublayer packet.


Comparison of AAL 5 against AAL 3/ 4

We can determine the relative efficiencies of protocol overhead for carrying a 230 byte Ethernet frame across a local ATM using both ATM 5 and ATM 3/ 4.

Table 8.5  Comparison of Protocol Overhead between AAL 5 and AAL 3/ 4

It can be seen that AAL 5 has 86.8% efficiency whereas AAL 3/ 4 only gives 72.3% efficiency.


Summary

ATM uses 53 byte cells to allow optimisation of hardware, to facilitate traffic mixing and reduce transport delay.
ATM cells carry virtual circuit routing information in the form of VCIs and VPIs.
ATM switching and routing are complex functions that are scalable to any size of network.
AAL functions allow legacy traffic to be carried in an ATM network.
ATM is a new technology and work is currently in progress to bring the full promise of ATM to a reality.
The future of ATM is open to question however. Popularity of ATM is waning because industry is unsure where to use it. ATM has already been placed in backbones and has been used as a pure data backbone.
Gigabit Ethernet has taken much of the market from ATM in the not-data-only backbone market.