background image
550 Chapter 8: WAN Protocols and Design
header compression, only the TCP header is compressed; all other headers and data remain
uncompressed. As its name suggests, payload compression compresses the payload of the
Frame Relay frame.
Regardless of which type of compression is used, the Frame Relay header itself cannot be
compressed. If the Frame Relay header were compressed, the intermediate Frame Relay
switches would not be capable of forwarding the frames.
Payload Compression
Figure 8-18 provides the basic concept behind payload compression and shows what is
compressed:
Figure 8-18
Frame Relay Payload Compression
If payload compression was used on the VC between Albuquerque and Yosemite, the Frame
Relay header would remain intact, but the packet (the payload) would be compressed before
transmission and uncompressed upon reception.
Two types of payload compression are available. The first historically used the STAC algorithm,
which predicts the values that follow the earlier bytes in the compressed payload. The algorithm
did not follow any standard. That process works fine, but it can run only in software--no
support for this algorithm exists for Frame Relay on the Versatile Interface Processor (VIP) or
the Compression Service Adapter (CSA).
The second payload compression option is to use the Frame Relay Forum standard com-
pression. The FRF.9 Implementation Agreement (IA) defines the details and is available free
from the Frame Relay Forum if you would like to see more details (http://www.frforum.com).
The FRF.9 document calls for the use of the STAC algorithm as well, but with some details that
differ from the original Cisco protocol. Cisco has added support for the FRF.9 payload
compression into the CSA and the VIP2. Even if compressing in software, Cisco recommends
using the FRF.9 payload compression over the original Cisco implementation of STAC.
Yosemite
Seville
Albuquerque
Compressed
FR Packet
ch08.fm Page 550 Monday, March 20, 2000 5:17 PM