ATM-Based Protocol Interworking and

Public Service Offering

This part provides the reader with in-depth study of ATM interworking with higher layer
protocols as well as current and planned public service offerings based on ATM technology.

ATM Based Protocol Interworking

This covers some general principles of protocol interworking using ATM, goes on to summarize
the current state of standardization. Next, there is a discussion of Data Exchange Interface (DXI)
which offers low speed ATM. Frame relay, SMDS, and IP protocols interworking over an ATM
network and interworking with ATM end systems are then described.

Interworking principles
This subject covers the general subject of interworking Specific Service (SS) higher layer
protocols using ATM. Specific Services are either interworked over ATM or to an ATM based
end system using network interworking. The higher layer network interworking protocols that
have been defined to date include frame relay, multiprotocol (including IP), and SDMS.

Network Interworking
The concept of network interworking is formally defined in ITU-T Recommendations 1.555
which defines Frame Relay Services (FRS) interworking with B-ISDN. This concept is generalized
to any Specific Service employing network interworking in one of the two scenarios:
interworking over an ATM network, and interworking with an ATM end system. In 1.555 these
are called network interworking scenarios 1 and 2 respectively.

The figure illustrates the network interworking of a Specific Service (SS) over an ATM network.

The physical configuration is shown in the diagram at the top of the figure, and the logical
protocol stack interfaces are shown at the bottom of the figure.

1
 I I Node 2
Node 1
W ATM W
`
Network
F F

Service
Specific End
System

Service
Specific
End
System

Upper
Upper
Layers Layers

SSP-SSCS SSP-SSCS Service

Service
Specific CP AAL
Specific
S CP AAL S
Protocol Protocol
S SP
(SSP) ATM ATM
(SSP)
P
ATM
PHY Networking Interworking over an ATM
PHY
PHY PHY
PHY
network

2
The below figure illustrates networking interworking of a Specific Service with an ATM end
system. The same style used in the previous figure is employed, and the interworking function
(IWF) is identical.

ATM

UNI
I

W ATM
F
Netwo
rk

Service ATM
Specific End End
System System

Upper
Upper
Layers Layers

SSP-SSCS SSP-SSCS
Service
Specific S CP AAL CP AAL
Protocol S
(SSP) P ATM
ATM
ATM
PHY PHY PHY
PHY

Network Interworking with an ATM end System

3
Service Interworking
The below figure illustrates the concept of service interworking using the same style of a
Service
Specific and protocol stack as was used for network interworking.
physical configuration
UNI
ATM
UNI
I

W ATM
Netwo
F rk

Service ATM
Specific End
End System
System

Upper
Upper
Layers
layers
ATM-ES
SSP-ES Higher Layers Higher layers
Higher layers
Interworking
SSP-SSCS SSCS
Service
Specific S CP AAL CP AAL
Protocol S
(SSP) ATM
ATM
P
ATM
PHY PHY PHY
PHY

Service Interworking Concept

Data Exchange Interface (DXI)

4
Data Exchange Interface supports the V.35, RS449, or the HSSI DTE-DCE interface at speeds
from several kbps up to and including 50 Mbps. ATM DXI specifies the interface between a DTE,
such as a router, and a DCE, usually called an ATM CSU/DSU, which provides the conversion to
an ATM UNI. Although the ATM DXI is normally thought of as a DTE-DCE interface specification,
there is no reason that it cannot be used as a longer distance access protocol over nxDS0, DS!,
and nxDS1 access lines. The SMDS DXI will be used in this manner as well. The ATM DXI is an
example of relatively simple network interworking with ATM.

The ATM DXI interface is managed by the DTE through a Local Management Interface
(LMI), while the ATM UNI Interim Local Management Interface (ILMI) Simple Network
Management Protocol (SNMP) messages are passed through to the DTE as shown.

ATM UNI ILMI

DTE
(Router, ATM Switch
Local ATM DXI LMI
Switch) DCE (CSU/DSU)

ATM DXI ATM UNI

ATM Data eXchange Interface (DXI) Configuration

Let’s now take a look at the three major modes of DXI: mode 1a, mode 1b, and mode 2. The
maximum number of VCCs supported is determined by the number of addressing bits, 10 for
mode 1 and 24 for mode 2. AAL5 is supported in all modes and rests of the options are given in
the table below:

Characteristics Mode 1a Mode 1b Mode 2

Maximum number 1,023 1,023 16,777,215

of VCCs

AAL5 Support Yes Yes Yes

AAL3/4 Support No Yes Yes

Maximum DTE

5
 SDU Length

AAL5 9,232 9,232 65,535

AAL3/4 N/A 9,224 65,535

ATM
BitsDXI- Mode 1a and Mode
in FCS 16 1b 16 32

Both modes 1a and 1b define DCE support AAL5. The DTE SDU is encapsulated in AAL5 CPCS
and then segmented into ATM cells using AAL5 CPCS and SAR sub layer functions. The 2-octet
frame check sequence (FCS) is same as that used in frame relay and HDLC and hence much
existing DTE hardware can be supported model.

DTE-SDU DTE-SDU

DXI AAL5 CPCS

DXI DATA LINK Mode 1a, 1b Data AAL5 SAR

AAL5 Link ATM ATM

UNI
ATM DXI DXI PHY Layer ATM UNI

DXI Physical Layer Physical Layer

Flag DXI Header DTE-SDU DXI FCS Flag

1 2 0-9, 232 2 1 Octets

Mode 1b adds support for the AAL ¾ CPCS and SAR on a per VCC basis.

6
ATM DXI- Mode 2
Mode 2 uses the same interface between DTE and DCE regardless of whether the VCC is
configured for AALS or AAL ¾.

The DTE must place DTE SDU inside the AAL ¾ CPCS header and trailer and then the DCE
performs the appropriate function depending upon whether the VCC is configured for AAL ¾ or
AAL5.

Multiprotocol over ATM AAL5

IETF standard RFC 1483 defines how a number of commonly used protocols can be routed or
bridged over ATM Adaption Layer 5 (AAL5). RFC 1483 defines two methods: protocol
encapsulation and VC multiplexing. Protocol Encapsulation allows for multiple protocols to be
multiplexed over a single ATM “Virtual Circuit (VC)” as defines in RFC 1483, which is the same
thing as an ATM virtual channel connection (VCC). This is the same term used in most other
standards. The VC multiplexing method assumes that each protocol is carried over a separate
ATM VCC. Both of these methods define the AAL5 Common Part Convergence Sublayer (CPCS)
Protocol Data Unit (PDU) format, also called the payload format. We first cover the protocol
encapsulation and then the VC multiplexing method.

Protocol Encapsulation
Protocol encapsulation operates by prefixing the Protocol Data Unit (PDU) with an IEEE 802.2
Logical Link Control (LLC) header, and hence we call this LLC encapsulation. The LLC header
identifies the PDU type. This method is designed for public network or wide area network
environments where a premises device would send all protocols over a single VCC, such as in a
PVC environment where the pricing structure favors a small number of PVCs.

R VCCs
R
VCCs

R B B B

Bridge token ring

Routing and
LLC Encapsulation Bridging7 use of LLC
- Routing Encapsulation
LLC Encapsulation - Bridging
Selection of Multiplexing Method
Either of the two types of multiplex methods, encapsulated or VC multiplexing, can be used
with PVCs and SVCs. The method is selected by a configuration option for PVCs. SVCs require
information elements in the signaling protocol for the two routers to communicate whether
protocol encapsulation or VC multiplexing was being used, and when using VC multiplexing,
whether the original LAN FCS is being carried.

ATM DXI Header Formats

The DXI frame address (DFA) is mapped into the low order bits of the VPI/VCI by the DCE. The
congestion notification (CN) is mapped from the last ATM cells of the PDU Payload type (PT)
congestion indication. The DTE can set the CLP bit so that the DCE will in turn set the CLP bit in
the ATM cell header with the same value, thus allowing user to make some PDU’S as a low loss
priority.

|8| |7| |6| |5| |4| |3| |2| |1|

1 DFA R 0

2 DFA CN R CLP 1

2-Octet DXI Header Format