IP over ATM techniques

Kingkarn Sriprasarn (g4165207@nontri.ku.ac.th)

Department of Computer Engineering
Kasetsart University
Bangkok 10900, Thailand

Abstract

The question of how best to integrate Asynchronous Transfer Mode (ATM) technology with
Internet Protocol (IP) and how well ATM will inter-operate with existed LAN technologies is
critical to the success of the ATM. In this paper, the various proposals for running IP are
presented. Well-known method are LAN Emulation (LANE), Classical IP over ATM (CLIP)
and the newest one; Multiprotocol over ATM (MPOA). The strengths and weakness of each
method will be compared.

Keywords

IP, ATM, LAN Emulation, Classical IP over ATM, Multiprotocol over ATM

I. Introduction

Asynchronous Transfer Mode (ATM) has received much attention. ATM has emerged as the
most suitable technology for the next generation of communication networks. The capability
of ATM to integrate data, voice, and video information on a common communications
network, while providing quaranteed Quality of Service (QoS) to individual connections, is
one of the technologies major benefits. However, ATM is connection-oriented whereas the
vast majority of modern data networking protocols are connectionless. This mismatch has led
to complexity, inefficiency, and duplication of functionality in attempting to apply ATM
technology to data communications.

The Internet Protocol (IP) has also seen very rapid growth in the last several years. IP is
connectionless, but many applications above IP employ a connection-oriented transport
protocol. An efficient mapping of IP onto ATM must consider the characteristics of the
application and the transport protocol in deciding whether to establish and end-to-end ATM
connection on behalf of and specific flow [Cole96].

Now that various standards and industry organizations (such as the ATM Forum and the
Internet Engineering Task Force – IETF) have completed work on defining and specifying the
fundamental aspects of the ATM protocols and standards. The heart of the problem is the fact
that there are a number of existing and a few emerging options and specifications for
supporting LAN traffic over ATM. Among the existing options are the ATM Forum’s LAN
Emulation (LANE) [Forum1], IETF’s Classical IP over ATM (CLIP) [Laub98], and emerging
options are Multi-Protocol over ATM (MPOA) [Hein93][Forum2].

This paper is organized as follows: Section II presents an overview of the architecture of

ATM networks, ATM signaling protocols, ATM addressing models and ATM routing
protocols. Section III attended to each of the internetworking of ATM: LANE, CLIP and
MPOA. Finally, these various techniques are compared in its strength and weakness.
II. ATM signaling and addressing

An ATM network consists of a set of ATM switches interconnected by point-to-point ATM

links or interfaces. ATM switches support two kinds of interfaces: user-network interfaces
(UNI) and network-node interfaces (NNI). UNI connect ATM end-systems to an ATM
switch, while an NNI may be imprecisely defined as an interface connecting two ATM
switches together; slightly different cell formats are defined across UNI and NNI.

ATM networks are fundamentally connection oriented. This means that a virtual circuit needs
to be set up across the ATM network prior to any data transfer. ATM circuits are of two types
: virtual paths, identified by virtual path identifiers (VPI); and virtual channels, identified by
the combination of a VPI and a virtual channel identifier (VCI). A virtual path is a bundle of
virtual channels, all of which are switched transparently across the ATM network on the basic
of the common VPI. For ATM connections have two fundamental types:
• Permanent Virtual Connections (PVC): A PVC is a connection set up by some external
mechanism in which a set of switches between an ATM source and destination ATM
system are programmed with the appropriate VPI/VCI values. ATM signaling can
facilitate the set up of PVCs,but PVCs always require some manual configuration
• Switched Virtual Connections (SVC): A SVC is a connection that is set up automatically
through a signaling protocol. SVCs do not require the manual interaction needed to set up
PVCs and are likely to be much more widely used.

ATM signaling protocols vary by the type of ATM link-ATM UNI signaling is used between
an ATM end-system and an ATM switch across an ATM UNI; ATM NNI signaling is used
across NNI links. Any signaling protocol, of course, requires an addressing scheme to allow
the signaling protocol to identify the sources and destination of connections. The ATM Forum
evaluated two fundamentally different models for addressing. These two models differed in
the way in which the ATM protocol layer was viewed in relation to existing protocol layers,
in particular, existing network layer protocols such as IP, IPX, and so on. These existing
protocols all have their own addressing schemes and associated routing protocols.

A. Peer model

This model was known as the peer model, since it essentially treats the ATM layer as a peer
of existed network layers. ATM endpoints would be identified by existed network layer
address (such as IP address), and ATM signaling requests would carry such addresses.
Existing network layer routing protocols (such as IGRP and OSPF) would also be used within
the ATM network to route the ATM signaling requests, since these requests, using existing
network layer addresses, would look essentially look like connectionless packets.

B. Overlay model

This model sought to decouple the ATM layer from any existing protocol, defining for it an
entirely new addressing structure. By implication, all existing protocols would operate over
the ATM network. For this reason, the model is known as the subnetwork or overlay model.
The overlay model requires the definition of both a new addressing structure, and an
associated routing protocol.

All ATM systems would need to be assigned an ATM address in addition to any higher layer
protocol addresses it would also support. All protocols operating over an ATM subnet would
also require some form of ATM address resolution protocol to map higher layer addresses
(such as IP addresses) to their corresponding ATM addresses. Note that the peer model does
not require such address resolution protocol. By using existing routing protocols, the peer
model also may have precluded the need for the development of a new ATM routing protocol.
The overlay model, by decoupling ATM from other higher protocol layers, allows each to be
developed independently of the other. Both ATM and evolving higher layer protocols are
extremely complex and coupling their development would likely have slowed the deployment
of ATM quite considerably. For two addressing models, Figure 1 and Figure 2 have shown
Peer model and Overlay model respectively.

Fig. 1 Peer model of ATM addressing

Fig. 2 Overlay model of ATM addressing

III. IP over ATM Techniques

A. LAN Emulation (LANE)

There are two fundamentally different ways of running network layer protocols across an
(overlay model) ATM network. One of these methods that carry network layer packets across
an ATM network is known as LAN Emulation. The ATM Forum's LAN Emulation (LANE)
specification defines mechanisms that allow ATM networks to coexist with legacy systems,
thereby providing a scalable migration path to ATM. The function of the LANE protocol is to
emulate a local area network on top of an ATM network as the name suggests. In other words,
the LANE protocols make an ATM network look and behave like an Ethernet or Token Ring
LAN.

LANE provides a translation layer between the higher-level connectionless protocols and the
lower-level connection-oriented ATM protocols. The ATM layer accepts the cell payload
from a higher layer, appends the header, and passes the resultant fixed-length cell to the
physical layer below. The ATM adaptation layer (AAL) sits above the ATM layer. The AAL
formats data into the 48-byte ATM cell payload, a process known as segmentation. Because
ATM can carry multiple traffic types, several adaptation protocols, each operating
simultaneously, can exist at the adaptation layer. AAL type 5 is used for LAN Emulation.
LANE sits above AAL5 in the protocol hierarchy. It makes the connection setup and
handshaking functions required by the ATM network from the higher protocol layers and thus
is completely independent of upper-layer protocols, services, and applications. Conversely, it
maps the MAC address-based data networking protocols into ATM virtual connections so that
the higher-layer protocols think they are operating on a connectionless LAN. LANE protocol
Architecture has shown in Figure 3
 Fig. 3 LANE Protocol Architecture

The LANE specification is based on a client-server implementation model. An emulated LAN

consists of one LAN Emulation service and multiple LECs communicating through the LUNI
(LANE UNI). A LEC (LAN Emulation Client) is a combination software and hardware agent,
embed within networking devices, for handling data forwarding, address resolution, and other
control functions. The LANE service consists of a LAN Emulation Server (LES), a Broadcast
and Unknown Server (BUS), and a LAN Emulation Configuration Server (LECS).

ATM supports only point-to-point (unicast) and point-to-multipoint (broadcast or multicast)

connections. The LES and BUS work together to transfer unicast and broadcast traffic:
• The LES handles address resolution and control information. Its primary job is to register
and resolve MAC addresses to ATM addresses.
• The BUS is designed for carrying broadcast data, such as TCP/IP address resolution
broadcasts or Novell Service Adverting Protocol (SAP) messages. It also handles all
multicast traffic. Finally, it broadcasts the initial unicast frames sent by the LEC while the
LES works in tandem to provide the appropriate ATM address for establishing a data-
direct VCC.

B. Classical IP over ATM (CLIP)

This model is defined in the RFC 2225 and defines the standard for the initial application of
IP and ARP over ATM networks for an logical IP subnetwork (LIS), which is an ATM
network where all the members of the LIS share a common network prefix. Form this name
"Classical" refers to the treatment of the ATM host adapter as a networking interface to the IP
protocol stack operating in a LAN-based paradigm. In the classical model the end-to-end IP
routing architecture stays the same. IP addresses are resolved to ATM addresses by use of an
ATMARP service within the LIS-ATMARPs stay within the LIS. One IP subnet is used for
many hosts and routers. Each VC directly connects two IP members within the same LIS.

Classical IP is the proposed solution for (partial) IP connectivity over ATM. It is constrained
to the operation of a subnetwork (LIS). It is to be noted that the necessary blocks for the
implementation of a Classical IP over ATM stack introduce redundancy in host identification.
Suppose an example that a user wishes to access a remote host belonging to the same LIS.
First, the domain name is resolved into an IP address. The IP layer hands this IP address to
the underlying layer which, in the Classical IP model, corresponds to ATMARP, a modified
version of the ARP protocol. This layer translates via a server the IP address to the VPI/VCI.
The IP layer then communicates with the ATM interface through this connection endpoint.
This protocol architecture is illustrated in Figure 4
 TCP UDP

IP

ATMARP

UNI
Signaling

ATM

Fig. 4 Classical IP protocol stack

ATMARP server responds to queries from hosts for internetwork layer addresses with an
ATM address. By reducing one step in the process of setting up an ATM connection for data
transfer, helps to minimize broadcast traffic in the subnet. The ATMARP server provides this
service to all IP end-stations that are directly attached to the ATM network in a LIS. This
model applies only to IP hosts, while LANE supports different internetwork layer protocols.

C. Multi-Protocol over ATM (MPOA)

Multi-Protocol over ATM (MPOA) has two different methods for carrying connectionless
network interconnect traffic, routed and bridged Protocol Data Units (PDUs), over an ATM
network. The first method, LLC Encapsulation, allows multiplexing of multiple protocols
over a single ATM virtual circuit. The protocol of a carried PDU is identified by prefix the
PDU by an IEEE 802.2 Logical Link Control (LLC) header. The second method, VC Based
Multiplexing, does higher-layer protocol multiplexing implicitly by ATM Virtual Circuits
(VCs).

An MPOA system would consist of a collection of : Layer 3 switches (called Edge Devices in
the MPOA specification) which support one or more ports to legacy LAN or WAN networks;
ATM-attached end-system implementing the MPAOA protocol (called MPOA hosts); and
Route Servers, all connected to an ATM network. Edge devices would implement layer 3
packet forwarding, but would not support routing protocols. These would be implemented on
the route servers, which would interact with each other, and with conventional routers (either
on, or outside, the ATM network), using conventional routing protocols (e.g. EIGRP, OSPF,
etc.).

All MPOA-capable devices--MPOA hosts, edge devices, and routers--would support a

MPOA client, where each such client would support both one or more layer 3 addresses, and
an ATM address. The layer 3 addresses associated with a MPOA client would repersent either
the layer 3 address of the associated node itself (in the case of a MPOA host, for instance), or
the layer 3 addresses (e.g. IP subnets) reachable through the node (in the case of a edge device
or router). MPOA clients would connect to a MPOA server, and register their ATM
addresses, as well as the layer 3 addresses reachable through them. For the architecture of the
MPOA protocol has shown in Fingure 5.
 Fig. 5 Architecture of the MPOA Protocol

IV. Comparison of IP over ATM techniques

From the previous sections that describe many techniques for internetwork IP over ATM, in
this section have summaries of their strengths and weakness. Some of these can be compared
with the others. Classical IP over ATM model has the advantage of transparent integration
into the existing architecture. Its strength is that it allows all existing applications to run
without modifications inside an native ATM host. The NHRP (NBMA Next Hop Resolution
Protocol) is a proposal for a scalable architecture for the provision of IP over ATM. It extends
the CLIP model by enabling the establishment of end-to-end ATM connections between IP
hosts, even if they do not reside on the same LIS. NHRP relies on a set of servers which carry
out address resolution between IP and ATM addresses. Quality of service provision is not
addressed similar to LANE that can not support Qos. But in MPOA this feature, Quality of
Service, is supported.

In logical client-server structure of MPOA, and the functions performed by the protocol, are
quite analogous to those of the LAN Emulation protocol. Where LANE determines the LEC
client through which a particular MAC address is reachable, and the client's ATM address, so
MPOA performs corresponding operations upon layer 3 addresses. Similarity, while the
LANE protocol is complicated by the support of MAC bridges, and the extension of ELANs
across and between such bridges, so the MPOA protocol is complicated by the need to extend
layer 3 subnets across and between edge swithes.

LANE use the unique benefits of ATM, its Qos guarantees. LANE is defined to use only
UBR (Unspecified Bit Rate) and ABR (Available Bit Rate) connections, since it is these that
map best to the connectionless nature of MAC protocols. At best, therefore, all current
network layer protocols today expect and deliver only a "best effort" service--precisely the
type of service that the ABR service was designed to offer. Much as LANE adapts ATM's
connection-oriented nature to offer the same type of connectionless service that is expected by
network layer protocol, so ABR hides the guaranteed QoS features of ATM to offer the best
effort service expected by these protocols. As such, ABR and LANE perfectly complement
each other.

Classical IP over ATM model preserves the host requirements, in the context of IP over
ATM, communications between two nodes on two different LISs on the same ATM network
must traverse each ATM router on the intermediate hops on the path between the source and
destination nodes. This is clearly inefficient, since the ATM routers become bottlenecks; this
also precludes the establishment of a single connection with a requested QoS between the two
nodes. One of the limitations of CLIP is that it does not address the issue of connection set-
up latency. Unlike LANE, it does not have a default data path on which data can be sent prior
to address resolution, connection routing, and establishment. The ongoing work on extensions
to the Classical IP over ATM model to eliminate this limitations.

In [Dris97] has the performance comparison between Classical IP over ATM and LAN
Emulation. The result have shown that the Classical IP over ATM is more efficient than LAN
Emulation because of lower overhead. Both Classical IP over ATM and LAN Emulation can
now be used in many network designs and the associated implementation. The question
remains as to which one to use. Generally, if the ATM network is to be a pure IP network,
then Classical IP over ATM is a common choice. If the primary protocol is not IP, only LAN
Emulation will be able to carry the traffic today.

V. Conclusion

This paper explain how many techniques of internetwork IP over ATM. Different approaches
to ATM deployment yield quite different results with respect to the ability of TCP/IP
applications to fully exploit ATM functionality. Both LAN Emulation and Classical IP over
ATM localize host changes below the IP layer, and therefore may be good first steps in the
ATM deployment. However, these approaches are likely to be inadequate for full utilization
of functionality that ATM is expected to provide.

The approach proposed in this paper leverages the existing technologies, minimizes new
development, imposes no new requirements on ATM, allows for small, incremental changes
with immediate payoffs, while at the same time retains backward compatibility with the
existing schemes, such as LAN Emulation and Classical IP over ATM.

VI. References

[Alle95] A. Alles, “ATM Internetworking,” Cisco Systems, Inc., May 1995

[Bonj98] D. Bonjour, O. Elloumi, and H. Afifi, “Internet applications over native ATM,”
Computer Networks and ISDN Systems, Vol. 30, pp. 1097-1110, 1998

[Cole96] R. Cole, D. Shur, and C. Villamizar, “IP over ATM: A framework document,” IETF
RFC 1932, April 1996

[Dris97] D.J. Driscoll, N. Mehravari, and M.H. Olson, “Performance Comparison Between
ATM LAN Emulation, Classical IP over ATM, and Native ATM in a Multi-Platform Multi-
Operating System Environment,” MILCOM 97 Proceedings, Vol. 1, pp. 434-438, 1997

[Forum1] LAN Emulation over ATM-LUNI Specification, version 2.0, The ATM Forum, July
1997

[Forum2] Multiprotocol over ATM Specification, version 1.0, The ATM Forum, July 1997

[Hein93] J. Heinanen, “Multiprotocol Encapsulation over ATM Adaptation Layer 5,” IETF
RFC 1483, July 1993

[Laub98] M. Laubach, J. Halpern, “Classical IP and ARP over ATM,” IETF RFC 2225, April
1998
[Newm98] P. Newman, G. Minshlall, and T.L. Lyon, “IP Switching—ATM under IP,”
IEEE/ACM Transaction on Networking, Vol. 6, pp. 117-129, April 1998

[Rekh95] Y. Rekhter, D. Kandlur, “Phasing ATM Technology into an IP Environment,”

International Conference on Computer Communication and Networks 1995, pp. 486-493

[Ritz98] S. Ritzenthaler, “IP or ATM versus IP over ATM: the Role of the ATM Forum and
the IETF in Setting Standards,” IEEE International Conference on ATM 1998, pp. 1-5