|
April 1997
By Lawrence G. Roberts, Connectware Inc.
Cells In Frames
CIF: Affordable ATM, At Last
The Cells in Frames spec delivers ATM's quality of service and flow control--without the need to replace Ethernet and token ring LANs
|
|
For all of ATM's pluses, there's a big minus that makes it a nonstarter in the minds of many networkers: price. Getting off the dime would be a no-brainer if running it to the desktop didn't cost so much.
But a new spec eliminates the issue of expense. Known as Cells in
Frames (CIF), it defines a way to send ATM protocols over Ethernet and
token ring nets--delivering all the benefits of ATM networking,
including quality-of-service guarantees, low and predictable delays,
and seamless integration of voice, video, and data traffic.
What's more, CIF actually improves on native ATM in some key
aspects. By extending flow-control mechanisms to the desktop, it
delivers Web pages up to 100 times faster than TCP/IP networks do. It
also reduces WAN costs--by virtually eliminating retransmissions and by
cutting ATM overhead by 25 percent.
Although it started as a LAN technology, CIF is now gaining the
attention of long-haul carriers. The Cells in Frames Alliance, a
consortium of 30 vendors a
nd end-users, is working on specifications
for CIF over Sonet and PPP (point-to-point protocol) links. The ATM
Forum not only has recognized CIF as a legitimate means of carrying
ATM protocols, but also is working with the CIF Alliance to set up
links between the technical committees of each body dealing with
traffic management and voice over ATM.
CIF Made Simple
|
Putting CIF to Work
|
Understanding the benefits of CIF means taking a look at how it
works. As a LAN protocol, CIF allows ATM communications among
workstations and switches in Ethernet or token ring nets. In a CIF
network, workstations continue to generate Ethernet or token ring
frames--but the frames contain one ATM header and the payloads of up to
31 ATM cells from the same ATM virtual circuit (VC). When the frames
reach a CIF edge swit
ch, they're either switched intact to another CIF
switch, or they're segmented into cells for transport on an ATM
network (see
Figure 1
).
Since the workstation still uses a standard Ethernet or token ring
network interface card (NIC), all that's needed is ATM signaling
software and a software "shim" between the NIC driver and the NDIS
(Network Device Interface Specification) layer of the workstation's
networking software. The shim adds a 4-byte CIF header to frames
before they're transmitted or removes the header as frames are
received. It also places outgoing data into multiple queues for ATM
quality-of-service (QOS) management and performs ATM explicit rate
flow control.
Otherwise, a CIF workstation is exactly the same as an ATM
workstation. It uses ATM signaling software and runs native ATM
applications as well as other applications over IP, IPX, and other
protocols. Since CIF has its own Ethernet ID, the workstation can
actually mix CIF frames and standard
Ethernet frames--but ATM's
explicit rate flow control cannot be supported for the non-CIF frames
if this is done.
Switches, on the other hand, need more in the way of modification.
A CIF edge switch differs from Ethernet and token ring switches in
four ways. First, it interprets the CIF header and ATM virtual
path/virtual circuit (VP/VC) information, in addition to other
protocols. Second, it supports QOS with multiple queues and uses a
weighted fair queuing algorithm to manage delay. (This addition would
also be required of switches using TCP/IP's resource reservation
protocol.) Third, CIF switches handle congestion by marking ATM
available bit rate resource management (ABR RM) cells with the maximum
rate they can support on a given VC. Finally, switch software must be
able to support ATM signaling.
Fortunately, these changes don't add up to much in the way of cost.
Although the first three require ASICs (application-specific
integrated circuits) in the switch, they don't significantly incre
ase
the price. The same goes for the software that's needed; although
another 8 Mbytes of memory are needed, the switch's cost goes up by
only a few percentage points. Thus there's every reason to believe
that CIF edge switches will cost about the same as conventional LAN
switches.
Why Use Frames?
|
Join the discusion on Message Server about Cells in Frame.
|
CIF is fundamentally different from native ATM. When ATM was
finalized in the 1980s, the belief was that high-speed switching would
make using short, fixed-length cells (53 bytes) a necessity. But the
ASIC technology now being used in 100Base-T and gigabit Ethernet
switches has proven that it's possible to switch variable-length
frames just as fast.
And using frames saves money. Since
CIF relies on current
frame-based technologies, it not only eliminates the NICs, but also
helps networkers save on leased-line overhead. For instance, ATM
overhead is about 30 percent as far as typical Internet traffic is
concerned. But variable-length CIF frames can reduce this to just 5
percent--which could make for significant long-term savings, since net
managers can send the same amount of data over lower-capacity leased
lines.
Further, using frames eliminates the need for SAR (segmentation and
reassembly)--and that means no more expensive SAR hardware at each
workstation. Thus CIF interfaces and NICs are inherently faster and
less expensive than ATM interfaces.
The Fix Is In
But even in using frames, CIF still delivers all the benefits of
ATM. These benefits--most of which are not available today in IP
networks--include low delay variance, VC-based switching, QOS
signaling/routing, and explicit rate flow control. When the decision
was made to use fixed-length cells, a fixed siz
e of 53 bytes also was
settled on to reduce voice delay to six milliseconds. But if
variable-length packets are permitted, both small packets for voice
and large packets for data are possible.
Small, fixed-length cells also were supposed to reduce delays for
all other kinds of traffic, but this has never been an issue for
high-speed lines. CIF limits frame length for all frames to 1,500
bytes, just like Ethernet; the highest possible delay variance is only
1 ms on 10-Mbit/s Ethernet and far less on OC3 (155-Mbit/s) or OC12
(622-Mbit/s) ATM trunks. Delay-variance requirements for voice and
video are relatively minimal--they only have to be under 10 ms to 30
ms--so CIF's 1-ms delay variances are a nonissue.
Like native ATM, CIF handles switching on a per-VC basis rather
than a per-frame basis. This is what makes high switching speeds,
call-based QOS, and call-based flow control possible. With the
introduction of tag switching in the IP world, there's clear
recognition that VCs are critical when
it comes to these features.
CIF also permits QOS signaling--which is the mechanism that allows
voice, video, and data to be mixed on the same wire without
degradation in delay variance. This important benefit is covered by
version 4 of the ATM Forum's signaling specification (SIG 4.0)--and
it's not available in IP networks today.
Another key ATM benefit is QOS-based routing. As defined in the ATM
Forum's private network-to-network interface 1.0 (PNNI 1.0) spec, it
allows load balancing across multiple ATM trunks, and it ensures that
all traffic is routed onto paths capable of handling the guaranteed
QOS and bandwidth. IP comes up short here, as well--but not CIF, which
fully supports PNNI.
With the Flow
Flow control with minimal control delay was always recognized as a
necessity for high-speed switched networks. To control the data flow
at greatly increased speeds, the ATM Forum developed explicit rate
flow control, which is defined in the forum's traffic management 4.0
(TM 4.0)
specification. TM 4.0 not only reduces switch buffering
requirements (and thus the cost of switches), but also cuts the time
required for page accesses like Web requests. With CIF, explicit rate
flow control can be extended to the desktop economically over Ethernet
or PPP dial-in; with IP, it can't.
|
BUILD YOUR OWN CUSTOM TABLE
How CIF Stacks Up
|
Actually, CIF goes even further in extending the benefits of
explicit rate flow control, since it permits true end-to-end flow
control even over Ethernet or token ring LANs (see
Table 1
). Flow
control manages traffic sources so that they do not send too much data
onto the network at any moment. If congestion occurs on any link in a
network, all t
he sources using that link must be told to slow
down.
This is absolutely necessary because data streams will be equally
bursty over one second, 10 seconds, or one million seconds. In other
words, simply underloading the network will not work. The critical
difference among flow-control techniques is in how long they take to
tell the source about congestion--and to get it under control.
TCP/IP's flow control method, the TCP protocol, uses a binary rate
flow-control algorithm: It slows down the data flow if the return path
indicates data has been lost and speeds up the flow when data is not
lost. TCP always oscillates within a period of 0.5 seconds to one
second on the Internet, losing data during congestion and
underutilizing the network at other times. TCP typically needs about
one second to stop an Internet data flow when there's increased
congestion.
In contrast, ATM's explicit rate flow control needs as little as 5
to 10 ms for the same task. Explicit rate flow control sends control
mess
ages called resource management (RM) cells to convey flow-control
information to the source. RM cells always take priority over data,
which typically decreases response time over TCP by a factor of 10 on
Internet connections. Because RM cells carry an explicit rate
(switches mark them with the fastest rate a VC will support), the
savings over TCP's oscillation is another factor of 5. And by
switching a cell to the source (instead of waiting for a round-trip
journey, as TCP does), notification times decrease by another factor
of 2 to 4. What it all adds up to is simple: Explicit rate flow
control is at least 100 times faster than TCP.
And because it's so much faster than TCP, explicit rate flow
control also reduces by a similar factor the amount of data that has
to be stored in switch buffers. IP routers typically are configured
with enough memory to buffer data from all inputs for one second,
whereas ATM switches with explicit rate need to be configured with
only about 10 ms of memory, a 100-fold redu
ction.
This results in four big benefits for the WAN. First of all, Web
page access time drops from 10 seconds to 0.1 seconds--in other words,
it's 100 times faster. Why? The same buffer that was required to
absorb data at a slow rate from TCP for one second can absorb data at
100 times that rate if the source can be stopped in 1/100 of the
time.
Second, the cost of switches comes down, typically by a factor of 2
to 7. Third, explicit rate switches have 100 times less delay variance
than IP switches, which makes them much better suited for interactive
applications. Finally, end-to-end deployment of explicit rate (which
CIF enables) results in virtually no data loss, whereas data loss
during peak hours on the Internet now runs 10 percent to 20 percent.
As a result, WAN line costs will come down by an equivalent
amount.
Wasted Space
When it comes to flow control, ATM clearly has the advantage over
TCP/IP. Unfortunately, the same cannot be said as far as overhead is
concerned. T
his is a major issue for net managers and carriers alike,
since both are in some way paying for wasted capacity. But CIF helps
address the problem by significantly reducing the overhead of ATM
traffic.
To understand why ATM overhead is a problem, consider the typical
220-byte Internet packet traveling on an ATM trunk. The ATM cell
header represents 10 percent overhead (5 bytes of a 53-byte cell). The
last cell of a packet carried on ATM is padded out to a full cell
using ATM Adaptation Layer 5 (AAL 5). This wastes half a cell on
average, adding 12 percent more overhead. On top of that, protocols
like Classical IP and LANE (LAN emulation) carry an IP header in each
packet, adding another 9 percent. And if explicit rate is not used
end-to-end, TCP retransmissions because of packet loss will add
another 20 percent of overhead. Thus, ATM carries up to 50 percent
additional overhead--or 20 percent more than TCP/IP.
|
CIF Cuts Down on Overhead
|
CIF can reduce the overhead to just 5 percent (see
Figure 2
). There
are virtually no retransmissions and no wasted space for AAL 5
padding. CIF still requires IP headers in the first packet for
routing, but they're not needed for every packet for the duration of
the call. Cif also reduces the number of ATM cell headers that are
involved; each CIF frame has to carry just one cell header, for up to
31 cells of payload.
[
Home
]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|
|
 |
|
|
