Frame Relay and ATM
WAN Technology
White Paper
The Growing Demand for ATM
Over the next five years, demand for Asynchronous
Transfer Mode (ATM) based networks is expected to
grow at a rapid rate. This growth will see ATM emerge as
a LAN technology for private enterprise networks as well
as a WAN technology for carrier/public network offerings.
This overall demand for ATM is generating a great deal
of attention in both the ATM Data Exchange Interface
(ATM-DXI) and Frame-based User-to-Network Interface
(FUNI) protocols for access into ATM networks. Because
of their roots in frame technology, both FUNI and ATM-
DXI are often compared with Frame Relay. Although
ATM has received more attention in the industry press,
Frame Relay currently has a much larger installed
base. As a result, protocols like Frame Relay to ATM
Service/Network Interworking will play a major role
in allowing existing Frame Relay networks to coexist
with ATM-based network environments. This paper
will clarify the issues surrounding both Frame Relay
and ATM technology by covering the following points:
• An explanation of FUNI and ATM-DXI
• A comparison of FUNI, ATM-DXI, and Frame Relay
• Frame Relay to ATM Service/Network Interworking
technical overview
• The PVC versus SVC debate
• The Role of Frame Relay and ATM technology in the
Cisco Internetwork Operating System (Cisco IOS™)
software and the overall product line
Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.
Page 1 of 8
This paper covers a number of technologies, focusing
on providing both technical information and a market
overview. In addition, the final section reveals Cisco’s
direction in the Frame Relay and ATM WAN technology
areas and emphasizes key differentiators in the following
areas:
• Maximum WAN bandwidth network throughput
through the use of compression
• Ease of configuration through Address Resolution
Protocol (ARP) and Inverse ARP services
• Quality of Service (QoS) through virtual circuit (VC)
prioritization
• Integrated LAN/WAN hardware support for seamless
dial-up/Integrated Services Digital Network (ISDN)
access, channelized T1/T3 interfaces, and ATM
switching in workgroup and campus backbone
environments
• Full Internet service access with integrated
security/encryption functionality
These features build upon existing strengths in the
Cisco IOS software and will deliver the best migration
path for customers looking to integrate Frame Relay and
ATM WAN technology into their networks.
FUNI and ATM-DXI Explained
FUNI and ATM-DXI are access protocols for ATM
networks and are designed to preserve end users’
investments in existing low-priced, frame-based hardware;
for example, the Cisco router and its serial interfaces.
Instead of requiring existing routers to provide ATM
cell-based interfaces, both FUNI and ATM-DXI use frames
on serial interfaces and transfer the segmentation and
reassembly (SAR) of user traffic into 53-byte ATM cells to
another point in the network. For FUNI (see Figure 1), this
point is the ATM switch while for ATM-DXI (see Figure
2), it is an ATM Channel/Data Service Unit (CSU/DSU).
Because FUNI and ATM-DXI can be run on the same
routers that currently use Frame Relay (or perhaps X.25),
they are appealing to end users who do not want to
purchase new routers with ATM cell interfaces or to
upgrade interfaces on existing routers.
Figure 1. FUNI Connection to ATM Network
Serial FUNI
Port Serial Port
ATM
Network
FUNI
Frames ATM Switch
Performs SAR
Customer
Premises
Figure 2. ATM-DXI Connection to ATM Network
Serial Port
CSU/DSU
DXI
Frames
Customer Premises
Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.
The similarity between FUNI and ATM-DXI occurs
because the FUNI specification evolved from the
ATM-DXI specification in the ATM Forum’s standards
work. Although FUNI and ATM-DXI are similar frame-
based protocols, it is important to note that FUNI has
more functionality for large WAN ATM networks
than ATM-DXI. FUNI uses the ATM Interim Local
Management Interface (ILMI) to manage the link between
the FUNI Data Terminal Equipment (DTE) router and the
FUNI Data Communications Equipment (DCE) switch.
This link can be either a WAN or LAN link, and it will
be managed by the ILMI. ATM-DXI lacks ILMI support
and cannot provide information about link status to the
ATM-DXI router. This makes ATM-DXI more susceptible
to link problems and less appropriate for WAN networks
than FUNI.
FUNI also utilizes serial line bandwidth more efficiently
than cell-based ATM because the variable-length frames do
not add as much overhead as ATM cells with their fixed
53-byte length that includes 5 bytes of header overhead. In
cases where large payload packets are being sent, FUNI
adds a fixed amount of overhead and can tolerate large
packets in one frame, whereas cell-based ATM service
cannot. Therefore, sending FUNI over a WAN link into
an ATM network is more efficient than using ATM-DXI,
ATM converting to ATM cells in an ATM CSU/DSU, and
Cells
sending the resulting cells over a WAN link into an
ATM network.
ATM ATM Cells ATM
Network
Page 2 of 8
FUNI, ATM-DXI, and Frame
Relay Technical Comparison
FUNI, ATM-DXI, and Frame Relay are quite similar in
terms of frame structure. Figure 3 shows that the header
structure for FUNI and ATM-DXI are identical. These two
header structures are similar to the Frame Relay header in
terms of bit positions, but FUNI and ATM-DXI use ATM
definitions for its fields while Frame Relay uses Frame
Relay definitions.
When the FUNI and ATM-DXI frames are segmented
into cells, the ATM-DXI and FUNI addresses map to the
ATM VPI/VCI (Virtual Path Identifier/ Virtual Connection
Identifier) using identical procedures as shown in Figure 4.
This process of converting FUNI/ATM-DXI frames into
ATM cells can be used as the basis for an interworking
function between Frame Relay and ATM. In this mapping
the following similarities exist:
• The Frame Relay DLCI address is mapped to VPI/VCI
address in ATM.
• The congestion notification (CN) bit performs the
same function as the Frame Relay forward explicit
congestion notification (FECN) bit. The network sets
this bit in frames and cells going from source to
destination based upon congestion levels for traffic
going in the forward direction. CN and FECN rely upon
the destination user equipment upper-layer protocols to
feed information back to the offending user equipment
via the upper-layer protocol. As interface speeds
increase, the effectiveness of FECN and CN decrease,
because of the round-trip delay generated in the
notification process to the offending user equipment.

Figure 3. FUNI, ATM-DXI, and Frame Relay Frame Header Structures

Flag Header User SDU (user traffic) FCS Flag

Frame Address RSVD 0

FUNI and ATM-DXI header
Frame Address CN RSVD CLP 1

DLCI Upper C/R 0

Frame Relay header
DLCI Lower FECN BECN DE 1

Figure 4. FUNI and ATM-DXI Frame Fragmentation into ATM Cells

Frame Flag Header User SDU (user traffic) FCS Flag

Frame address
bits map to
VCI/VPI bits

Cell Header Payload Header Payload Header Payload

Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.

Page 3 of 8
• The Frame Relay BECN bit does not have a similar
function in ATM either for FUNI or ATM-DXI. BECN
is a backward notification to a Frame Relay source
indicating that the traffic it sent has experienced
congestion. BECN allows the network to notify a Frame
Relay source directly about congestion in the network
by setting the BECN bit in frames going in the reverse
direction.
• The Frame Relay discard eligible (DE) bit and the
cell loss priority (CLP) bit perform the same function.
CLP/DE = 1 indicates that a cell/frame has a greater
probability to be discarded in the case where network
congestion requires cells/frames to be discarded.
• The Frame Relay C/R bit, which is passed transparently
between Frame Relay users, does not have a
corresponding bit in the FUNI/ATM-DXI header.
Although this mapping between Frame Relay and ATM
is convenient, it should be noted that other mappings are
possible.
Figure 5. Frame Relay/ATM Network Interworking Topology
Frame Relay Frame
Network Relay/ATM
Network
IWF
Frame Relay
End Station
Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.
Page 4 of 8
Frame Relay to ATM Service/
Network Interworking
Technical Overview
Having compared Frame Relay to ATM Interworking
functions in the previous section, this section will describe
the two major interworking network topologies:
• Frame Relay to ATM Network Interworking, which
provides an ATM transport between two Frame Relay
end stations
• Frame Relay to ATM Service Interworking, which
allows an ATM end station to communicate with a
Frame Relay end station without either side having
any knowledge about the protocol being used on the
other end
The basic topology for Frame Relay/ATM Network
Interworking is shown in Figure 5. It consists of Frame
Relay end stations on either side going through a Frame
Relay network to the Frame Relay/ATM Network
Interworking Function (IWF). The IWF is connected to an
ATM network, which acts as a transport medium for the
Frame Relay end stations. The Network IWF transparently
transports both data traffic and PVC signaling information
(the Link Management Interface (LMI)) through the ATM
network and effectively tunnels Frame Relay through
ATM. This facilitates Multiprotocol Encapsulation (RFC
1490) and other higher-layer functionality to be transported
over the network. The location of the Network IWF can
either be on a Frame Relay or an ATM switch. The
Network IWF can also be in a box external to either
network.
ATM Frame Frame Relay
Network Relay/ATM Network
Network
IWF
Frame Relay
End Station
The basic topology for Frame Relay/ATM Service
Interworking is shown in Figure 6. The Frame Relay/
ATM Service IWF acts as a protocol converter that allows
communication between a Frame Relay end station/
network on one end and an ATM end station/network on
the other end. (Note that the ATM end station can use the
more standard ATM User Network Interface (UNI) as well
as either FUNI or ATM-DXI.) The protocol conversion or
mapping function is similar to that described in the “FUNI,
ATM-DXI, and Frame Relay Technical Comparison”
section. Because protocol conversion is performed,
the Service IWF converts Frame Relay Multiprotocol
Encapsulation (RFC 1490) to ATM Multiprotocol
Encapsulation (RFC 1483) to ensure internetworking of
upper-layer protocols. This conversion is known as the
translation mode in the FRF.8 specification, and it also
allows Inverse ARP to function between RFC 1293 for
Frame Relay and RFC 1577 for ATM. There is also a
transparent mode that does not require this conversion.
When there are compatible upper-layer protocols between
the terminal equipment at both ends for applications such
as packetized voice, the transparent mode can be used.
Figure 6. Frame Relay/ATM Service Interworking Topology
ATM ATM FUNI
Network
ATM UNI
ATM DXI
Frame Relay
Network
FR/ATM
Service
IWF
Frame Relay
End Station
For further details on either of these techniques, please
refer to FRF.5 and FRF.8 published by the Frame Relay
Forum.
The PVC Versus SVC Debate
Another important issue for both Frame Relay and
ATM technology is the debate surrounding whether these
services should be based upon Permanent Virtual Circuits
(PVCs) or Switched Virtual Circuits (SVCs). PVCs are
virtual circuit connections between two locations that
Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.
Page 5 of 8
remain permanently set up as shown in Figure 7. SVCs,
by contrast, are virtual circuit connections between two
locations that get set up and torn down (switched) based
upon whether data is actually being sent as shown in
Figure 8. PVCs only require a one-time initial setup
between the switch and the router, but become
cumbersome and costly in networks requiring any-to-any
connectivity (that is, where the number of PVCs required
is proportional to n2 where n is the number of sites in the
network). In contrast to this, SVCs are continually being
set up or torn down based upon data traffic patterns.
Although SVCs entail this overhead, the benefit is that
virtual circuits are only established based upon data
demand. Therefore, the number of virtual circuits is
proportional to the number of actual conversations between
sites rather than the number of sites. SVCs are preferred in
networks that require any-to-any connectivity and dynamic
VC setup, whereas PVCs are better for partially meshed
networks designed to mimic leased-line topologies.
Figure 7. PVC Connection Schematic
PVC Remains Up
Permanently
ATM or Frame Relay
Network
Physical Physical
Access Access
Link Link
Figure 8. SVC Connection Schematic
SVC Setup and
Torn Down Based
upon Data Traffic
ATM or Frame Relay
Network
Physical Physical
Access Link Access Link
Currently, Frame Relay is PVC based in both
carrier/service provider network offerings and private
Frame Relay networks. During 1996, Frame Relay
SVC offerings will begin to emerge in private networks
requiring any-to-any connectivity as well as a few small
trial implementations in service provider offerings. Despite
this fact, the majority of Frame Relay networks will remain
PVC based through at least 1997.
In terms of ATM, PVCs and SVCs are both used depending
upon the application. For ATM-DXI, a static PVC is used
for the connection from the router through the ATM DSU
to the ATM edge switch as shown in Figure 9. Inside the
ATM network, a PVC is also used. For FUNI, both PVCs
and SVCs can be used. FUNI PVCs offer users the same
benefits of Frame Relay PVCs in the WAN with the ability
to have an end-to-end ATM solution with Quality of
Service and seamless-service ATM switches in the LAN.
FUNI SVCs offer similar capabilities with the added
benefit of dynamic setup and teardown of VCs based
upon data traffic. It is expected that FUNI will eventually
be more common as an SVC service, although early
implementations may be PVC-based.
For interworking ATM and Frame Relay, a variety of
permutations possible. At present, only PVC-based
ATM/Frame Relay Interworking is being specified in the
ATM and Frame Relay Forums. The ATM/Frame Relay
Network Interworking is PVC based, allowing a single
Frame Relay PVC to be mapped to a single ATM PVC and
for all Frame Relay PVCs to be mapped into a single ATM
PVC. The ATM/Frame Relay Service Interworking is also
PVC based and requires a one-to-one mapping between
Frame Relay and ATM PVCs.
The Role of Frame Relay and
ATM Technology in Cisco IOS
Software and Overall
Product Line
This section highlights the future directions of Frame Relay
and ATM technology in the Cisco IOS software. Frame
Relay/ATM Interworking technology will also be covered
in this context.
Figure 9. ATM-DXI PVC Connection to ATM Network
Serial Port
ATM
CSU/DSU
ATM
DXI
Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.
Page 6 of 8
In terms of Frame Relay technology, the Cisco IOS
software already has a large suite of features for Frame
Relay PVCs and will build upon this by providing the
following:
• Compression functionality based upon the Frame Relay
Forum’s FRF.9 Implementation Agreement (IA); this
complements the existing Payload and TCP/IP Header
Compression
• Enhanced security capabilities with Encryption over
Frame Relay
• Improved Prioritization with Per-VC Queuing; this
complements the existing Priority/Custom/Weighted
Fair Queuing (PQ/CQ/WFQ) and provides a further
degree of granularity
Cisco will also begin to offer Frame Relay SVC (DTE)
functionality in the Q4 ’96 timeframe. The Frame Relay
SVC features will emphasize similar functionality as the
PVC effort but will be more suited to any-to-any
connectivity networks.
In terms of ATM technology, Cisco already offers support
for the ATM-DXI 1a standard. In the FUNI area, Cisco
plans to deliver support for both FUNI DTE and DCE
functionality. The major differentiators in Cisco’s offering
will include:
• Integrated Internet Service access with security via
encryption for both the DTE and DCE devices
• Dial-up access (ISDN) as well as leased line services
for both the DTE and DCE devices
• Channelized T1 access for increased port density for
DCE devices
• Point-to-multipoint support for both the DTE and DCE
devices
• Integrated IP address resolution services for both the
DTE and DCE devices
• Compression over low-speed FUNI WAN links for
DTE devices
ATM PVC ATM
Network
ATM Cells
ATM
Edge Switch
These features will enable Cisco to offer an industry
leading FUNI implementation that is complementary
to existing Cisco IOS WAN services.
In terms of Frame Relay/ATM Interworking technology,
Cisco will emphasize Frame Relay/ATM Service
Interworking. Major differentiators in the Service
Interworking area include:
• Translation of multiprotocol Inverse ARP to permit
auto-configuration of Frame Relay and ATM endpoint
devices
• Interoperability of existing Frame Relay Compression
(FRF.9) to allow interoperation with Frame Relay
devices using compression to maximize network
throughput
• Per-VC queuing to allow end-to-end QoS with ATM
end users. This will be useful for mission-critical SNA
environments requiring fast response times
• Integral encryption for both Frame Relay and ATM
to provide seamless security
The Service Interworking functionality will initially
be PVC based.
Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.
Page 7 of 8
Conclusion
Frame Relay and ATM WAN technologies are growing
at a rapid rate. New services like Frame Relay SVCs,
Frame Relay/ATM Service Interworking, and FUNI are
emerging to permit migration and integration of today’s
PVC-based Frame Relay landscape into the SVC-based
ATM fabric of tomorrow. The Cisco IOS software provides
industry-leading functionality in these areas to support
all common industry standards. In addition, Cisco is
committed to providing its customers with value-added
implementations that give superior traffic prioritization,
Internet access, security, cost-optimizing data
compression, and integrated LAN/WAN software support.
Cisco continues to build on these defining characteristics of
the Cisco IOS software as Frame Relay and ATM WAN
technologies permeate into networks worldwide.
 Tel: 49 89 32 15070 Bedfont Lakes
Fax: 49 89 32 150710 Feltham, Middlesex TW14 8HA Cisco Systems (HK) Ltd
UK 7th Floor, The Park Place Building
Ireland Tel: 44 1 81 818 1400 231 Sarasin Road, Pathumwan
Cisco Systems Ltd. Fax: 44 1 81 893 2824 Bangkok 10330
Europa House, 4th Floor Thailand
Harcourt Street Asia Tel: 662 253 5315
Dublin 2 Cisco Systems (HK) Ltd Fax: 662 253 8440
Ireland Suite 1009, Great Eagle Centre
Tel: 35 3 1 475 4244 23 Harbour Road Argentina
Fax: 35 3 1 475 4778 Wanchai Cisco Systems Argentina
Cisco Systems Worldwide Offices Hong Kong Cerrito 1054, Piso 9
Italy Tel: 852 2583 9110 (1001) Buenos Aires
Corporate Headquarters Cisco Systems Italy Srl Fax: 852 2824 9528 Argentina
Cisco Systems, Inc. Centro Direzionale Milano Oltre Tel: 54 1 811 7526
170 West Tasman Drive Palazzo Raffaello Scala B 4P Cisco Systems (HK) Ltd Fax: 54 1 811 7495
San Jose, CA 95134-1706 Via Cassanese 224 Beijing Office
USA 20090 Segrate (Mi) Room 821/822, Jing Guang Centre Australia
World Wide Web URL: Italy Hu Jia Lou, Chao Yang Qu Cisco Systems Australia Pty Ltd
http://www.cisco.com Tel: 39 2 26 97 31 Beijing 100020 Level 17
Tel: 408 526-4000 Fax: 39 2 26 92 9006 China, PRC 99 Walker Street
800 553-NETS (6387) Tel: 86 10 501 8888 x821/822 North Sydney NSW 2060
Fax: 408 526-4100 The Netherlands Fax: 86 10 501 4531 Australia
Cisco Systems Tel: 61 2 9935 4100
Cisco Systems has more than 125 sales Stephensonweg 8 Cisco Systems (HK) Ltd Fax: 61 2 9957 4077
offices worldwide. To contact your 4207 HB Gorinchem New Delhi Liaison Office
local account representative, call Cisco’s The Netherlands Suite 119, Hyatt Regency Delhi Brazil
corporate headquarters (California, Tel: 31 183 622 988 Bhikaiji Cama Place, Ring Road Cisco Systems Do Brasil
USA) at 408 526-4000 or, in North Fax: 31 183 622 404 New Delhi 110 066 Rua Helena 218, 10th Floor
America, call 800 553-NETS (6387). India Cj 1004-1005 Vila Olimpia
Norway Tel: 91 11 688 1234 x119 Sao Paulo, SP CEP 04552-050
European Headquarters
Cisco Systems Fax: 91 11 611 7688 Brazil
Cisco Systems Europe s.a.r.l. Holmens Gate 4 Tel/Fax: 55 11 822 6095
Parc Evolic - Batiment L2 N-0250 Oslo Cisco Systems, (HK) Ltd Tel/Fax: 55 11 822 6396
16, Avenue du Quebec Norway Level 12, Wisma Bank Dharmala, JI
BP 706 Villebon Tel: 47 22 83 06 31 Jenderal Sudirman Kav. 28 Canada
91961 Courtaboeuf Cedex Fax: 47 22 83 22 12 Jakarta Selatan 12910 Cisco Systems Canada Limited
France Indonesia 150 King Street West
Tel: 33 1 6918 61 00
Portugal Tel: 62 21 523 9132 Suite 1707
Cisco Systems Portugal Fax: 62 21 523 9259 Toronto, Ontario M5H 1J9
Fax: 33 1 6928 83 26 Avda. da Liberdade 114-134 Canada
Intercontinental and Latin American
1250 Lisboa Cisco Systems Korea Tel: 416 217-8000
Headquarters Portugal Samik Rabidol Building 5th floor Fax: 416 217-8099
Cisco Systems, Inc. Tel: 351 1 340 45 31/2 720-2 Yuksam-2-dong, Gangnam-ku
170 West Tasman Drive Fax: 351 1 340 4575 Seoul, 135-082 Central America / Caribbean
San Jose, CA 95134-1706 Korea Cisco Systems, Inc.
USA South Africa Tel: 82 2 3453 0850 790 NW 107th Avenue, Suite 102
Tel: 408 526-7660 Cisco Systems South Africa Fax: 82 2 3453 0851 Miami, Florida 33172
Fax: 408 526-4646 Meintjie Parker House USA
328 Rivonia Blvd. Cisco Systems (HK) Ltd Tel: 305 228-1200
Japanese Headquarters Rivonia, Gauteng Kuala Lumpur Office Fax: 305 222-8456
Nihon Cisco Systems K.K. South Africa Level 5, Wisma Goldhill
Seito Kaikan 4F Tel: 27 11 807 4444 67 Jalan Raja Chulan Colombia
5, Sanbancho, Chiyoda-ku Fax: 27 11 807 4447 50200 Kuala Lumpur Cisco Systems Colombia
Tokyo 102 Malaysia Cra. 18 #86A-14
Japan Spain Tel: 60 3 236 5147 Bogota
Tel: 81 3 5211 2800 Cisco Systems Spain Fax: 60 3 236 5146 Colombia
Fax: 81 3 5211 2810 Avenida de Burgos, 17 Pl. 11 Tel: 57 1 296 0067
Edificio Triada II Cisco Systems Manila Office Fax: 57 1 616 3030
Austria 28036 Madrid The Executive Tower Centre
Cisco Systems Austria GmbH Spain Room 9, 24/F, Pacific Star Building Mexico
World Trade Center Tel: 34 1 383 2178 cor. Buendia Street, Makati Avenue Cisco Systems de México, S.A. de C.V.
A-1300 Vienna Airport Fax: 34 1 383 8008 Makati City Ave. Ejecito Nacional No. 926
Austria Philippines 3er Piso
Tel: 43 1 7007 6256 Sweden Tel: 632 892 4476 Col. Polanco C.P. 11560
Fax: 43 1 7007 6027 Cisco Systems AB Fax: 632 811 5998 Mexico D.F.
Arstaangsvagen 13 Tel: 52 5 328 7600
Belgium 117 60 Stockholm Cisco Systems (USA) Pte Ltd Fax: 52 5 328 7699
Cisco Systems Bruxelles Sweden 501 Orchard Road
Complex Antares Tel: 46 8 681 41 60 #04-11 Lane Crawford Place New Zealand
71 avenue des Pleiades Fax: 46 8 19 04 24 Singapore 238880 Cisco Systems New Zealand
1200 Brussels Tel: 65 738 5535 Level 16, ASB Bank Centre
Belgium Switzerland Fax: 65 738 2202 135 Albert Street
Tel: 32 2 778 42 00 Cisco Systems Switzerland P.O. Box 6624
Fax: 32 2 778 43 00 Grossrietstrasse 7 Cisco Systems (HK) Ltd Auckland
CH-8606 Naenikon/ZH Taipei Office New Zealand
Denmark Switzerland 4F, 25 Tunhua South Road, Section 1 Tel: 64 9 358 3776
Cisco Systems Tel: 41 1 905 20 50 Taipei Fax: 64 9 358 4442
Larsbjoernsstraede 3 Fax: 41 1 941 50 60 Taiwan, ROC
Dk-1454 Copenhagen K Tel: 88 62 577 4352 Venezuela
Denmark United Arab Emirates Fax: 88 62 577 0248 Cisco SystemsVenezuela
Tel: 45 33 37 71 57 Cisco Systems (Middle East) Calle Bajada de Los Curtidores
Fax: 45 33 37 71 53 PO Box 26095 Qta. Jakaranda - Alto Hatillo
City Tower 2 Caracas
Finland Sheik Zayed Road Venezuela
Cisco Systems Dubai, UAE Tel/Fax: 58 2 963 6140
Maistraatinportti 2A Tel: 971 4 318 788
FIN-00240 Helsinki Fax: 971 4 313 681 0396R
Finland
Tel: 358 1594 3090 United Kingdom
Fax: 358 1594 3093 Cisco Systems Ltd.
4 New Square
Germany
Cisco Systems GmbH
Max-Planck-Strasse 7, 3rd Floor
85716 Unterschleissheim
Germany

Cisco IOS, the Cisco IOS logo, and Cisco Systems are trademarks, and Cisco and the Cisco Systems logo are registered trademarks of Cisco Systems, Inc. All other trademarks, service marks, registered trademarks, or registered
service marks mentioned in this document are the property of their respective owners. 0196R

0496R

Copyright © 1996 Cisco Systems, Inc. All Rights Reserved.

Page 8 of 8