. 103
( 132 .)


ISO 0x00 00 00

EtherType (2 bytes)


Figure 7.83 Routed protocols

format for IP

LLC 0xAA AA 03

ISO 0x00 00 00

0x08 00

IP packet

Figure 7.84 IP encapsulation over AAL5

is pre¬xed with the IEEE 802.2 logical link control (LLC) header before encapsulation
in the PDU of AAL5. This is the scheme used for all IP over ATM systems. Figure 7.84
shows the format of the IP packet with the LLC pre¬x.
The LLC pre¬x is 8 bytes long and for IP the next 3 bytes indicate an EtherType
protocol and contain zeros. The remaining two bytes, 0x08 00, identify the packet as
being an IP packet. This is the encapsulation mechanism used to transport IP over AAL5
over ATM throughout the UMTS network.
There are two approaches to dealing with IP over ATM. The ¬rst sees the ATM network
as a LAN and divides this LAN up into logical subnetworks based on the IP addresses of
the hosts, similar to IP subnetting. This approach is known as classical IP over ATM. Here,
hosts on the same subnet communicate with each other over ATM connections and use
address resolution protocol (ARP) servers to resolve IP addresses to their corresponding
ATM addresses. Each subnetwork is interconnected using a router, and traf¬c between
subnets goes through the router. There is a problem here since even though hosts are on
different subnets, they are on the same ATM network so the process of passing through
one or more routers introduces a high degree of inef¬ciency into the system. This is
because IP packet headers must be examined at each hop, requiring that the whole IP
packet must be reconstructed by each router along the route.
The second approach expands on the classical IP over ATM model by providing a next
hop resolution protocol (NHRP). This protocol allows hosts to resolve ATM addresses
of hosts on other subnets and connect directly using an ATM end-to-end connection.
The concept is similar to that of DNS address resolution. Both are now discussed in
more detail.

7.15.3 Classical IP over ATM (CLIP)
As already mentioned, the ATM network is partitioned into logical IP subnetworks,
referred to as an LIS, with each of these subnetworks interconnected by an IP router.
An example of such a system is shown in Figure 7.85.

ATM Network


Router Router

Figure 7.85 Classical IP over ATM

Each host on an LIS will share the same IP pre¬x and subnet mask, which is similar
to a traditional IP subnetwork on a broadcast LAN. In contrast, though, the LISs are all
on the same ATM network, hence the term ˜logical™ subnet.
There are two different types of communication that may occur.

1. Communication between hosts on the same LIS. This is done through an end-to-end
ATM connection. However, prior to data transfer, a connection between the two
hosts must ¬rst be established. Consider two hosts, A and B, where A wishes to send
data to B. A knows the IP address of B, but requires its ATM address. As shown in
Figure 7.86, each LIS must contain a server, called an ATMARP server, which
provides the address resolution.
A sends an ARP request to the ATMARP server containing the IP address of B. The
server will look up B™s IP address, extract the corresponding ATM address and return
it to A. Actually, the ATMARP server sends an inverse ARP request to A, so that A
will reply with its IP and ATM addresses, which the server can then store. This
enables the ATMARP server to automatically build up a translation table. Once A
receives the ATM address of B, it can establish a connection with B using
ATM signalling.
2. Communication between hosts on different LISs. Each LIS will contain a router
which will forward packets not destined for the local subnet. The router either
forwards the packet to the destination host, or to another router, with the packet
being routed on a per-hop basis. This scheme will introduce a considerable delay
since each router is required to disassemble and reassemble the IP packet

CLIP and this form of address resolution is supported as an option in UMTS for use
on the Iu-PS interface, and it is likely that, if implemented, the ARP server would be
located in the SGSN. Originally, there was a requirement that CLIP be used, but this
has subsequently been changed as certain parties argued that the use of PVC connections
in UMTS was implemented for simplicity, which would then be negated by having to
use CLIP. Thus a manufacturer is at liberty to implement an operations and maintenance
(O&M) solution for address discovery.



1 1-530-3425435
B IP =
ATM = ??



A 1-530-1233415

B 1-530-3425435

. ... ...

Figure 7.86 Address resolution

7.15.4 Next hop resolution protocol (NHRP)
It was seen that CLIP is limited since communication between hosts in different LISs
is done through IP routers even though they are connected on the same ATM network.
What is required to overcome this shortfall is a mechanism to resolve IP addresses to ATM
addresses regardless of location in the network. This process is performed by NHRP.
Each LIS must contain an NHRP server. If a host needs an address resolution, it
sends the request to the NHRP server, which contains a table of mappings between IP
addresses and ATM addresses. The NHRP server performs the role of the ATMARP
server for requests to resolve addresses within the LIS. However, if the request is for an
address in another LIS, the NHRP server will forward the address resolution request to
the correct NHRP server for the LIS on which the destination host resides. The network
layout for the NHRP system, referred to as a non-broadcast multiple access (NBMA)
subnet, is shown in Figure 7.87.
The NHRP servers are interconnected and use a routing protocol in which, like an IP
router, an NHRP server can work out which NHRP server to forward the request to. Note
that the request may pass through a number of servers before reaching the destination
server. This NHRP server will then reply along the reverse path with the corresponding
ATM address, thus allowing the source host to directly establish an end-to-end ATM
connection with the destination. As the reply travels back to the source, the intermediate
NHRP servers will cache the mapping to speed up subsequent requests. This approach is

server server server



Router Router

Figure 7.87 NHRP

known as cut-through routing. The system still employs IP routers, which may be used
to transfer data while waiting for the direct connection to be established.

7.15.5 IP multicast over ATM
Both systems discussed so far are only for establishing a point-to-point or unicast con-
nection. However, the IP protocol supports multicasting, where packet transfer can be
point-to-multipoint or multipoint-to-multipoint. To service this, a mechanism is needed to
resolve such a request into a list of ATM addresses. Once a set of destination hosts is
established, a method is also needed to transfer data to all of these hosts.
To solve the problem, each LIS has a multicast address resolution server (MARS) which
resolves the mappings. This resolution is performed in the same manner as for unicast
address resolution by the ATMARP server.

Multicast server


Figure 7.88 Multicast server

Once a set of destinations is known, a multicast connection needs to be established.
This is done by one of two methods:

1. VC mesh: each host establishes a connection to each of the destinations.
2. Multicast server: here, each LIS contains a multicast server (MCS). A host will sent
a request to the MARS, which will return the address of the MCS. Packets are then
sent to the MCS, which will forward them to the multiple destinations. The MCS
builds either a point-to-multipoint or multiple point-to-point connections with the
destinations speci¬ed by the multicast packet. The system is shown is Figure 7.88.
The MARS and the MCS are logical units and can reside in the same physical device.

This chapter describes how ATM is used to provide the transport network for UMTS. A
detailed explanation of ATM is presented, speci¬cally with reference to its application
to UMTS. The interaction between ATM and the physical medium is described, again
with speci¬c reference to the PDH and SDH infrastructures that are used for UMTS, and
physical layer protocols such as inverse multiplexing for ATM and UTOPIA. In particular,
the extensive use of AAL2 for transfer of data, both real-time and non-real-time, across
the Iub/Iur interface is examined, as well as its use to transport real-time traf¬c between
UTRAN and the core network on the Iu-CS interface. UMTS is the ¬rst major application
for AAL2 switching, which allows AAL2 connections to be dynamically established and
released. This allows the implementation to create a static ATM infrastructure based on
PVCs and then dynamically run AAL2 over this. The AAL2 signalling protocol operation
is examined, with real-world examples using network traces. Inherent to ATM is the
provision of QoS, and the principles of operation of ATM QoS and traf¬c management,
and its relationship to UMTS QoS, is explored in depth. Also, the mechanism for transport
of IP over ATM, as used on the Iu-PS interface, is explained. Finally, some other aspects
of ATM such as network management and PNNI are described. While not explicitly
speci¬ed for use by 3GPP, they may be implemented to provide additional support and
¬‚exibility in the network.

3GPP TS25.414: UTRAN Iu interface data transport & transport signalling.
3GPP TS25.422: UTRAN Iur interface signalling transport.
3GPP TS25.424: UTRAN Iur interface data transport & transport signalling for CCH data
3GPP TS25.426: UTRAN Iur and Iub interface data transport & transport signalling for
DCH data streams.
3GPP TS25.432: UTRAN Iub interface: signalling transport.
3GPP TS25.434: UTRAN Iub interface data transport & transport signalling for CCH
data streams.

RFC 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5. Juha Heinanen.
July 1993.
ATM Forum: LAN Emulation over ATM 1.0, af-lane-0021.000.


. 103
( 132 .)