- Cisco IP/Multiprotocol Label Switching Specification Sheet

4-3
Data Center High Availability Clusters Design Guide
OL-12518-01
Chapter 4 FCIP over IP/MPLS Core
Typical Customer Requirements
The requirements are as follows:
• FCIP transport over an optimized IP/MPLS network
• Some type of compression mechanism (software or hardware)
• Security mechanism (IPSec, encryption, and VPN networks)
• End-to-end management of FCIP traffic
Compression
The primary objective of compression is to reduce the amount of overall traffic on a particular WAN link.
This is achieved when a data rate equal to the WAN link speed is compressed, thereby reducing the total
amount of data on the WAN link. In this case, non-compressed storage data requires all of the 45 Mb/sec
DS3 WAN connection. By enabling compression on the storage data (assuming an average of 2 to 1
compression), the effective utilization of the WAN link by storage traffic would be 22.5 Mb/sec. This
allows the WAN link to be used by other IP traffic. The second objective for compression may be to carry
more data over a WAN link than it is normally capable of carrying. An example of this is to compress a
90-Mbps Fibre Channel data stream and carry it over a 45-Mbps WAN link (still assuming an average of
compression ratio of 2 to 1).
There are several types of compression algorithms. The most common type used in data networks is
lossless data compression (LZS). This type of compression converts the original data into a compressed
format that then can be restored into the original data. The service adapter modules (7600-SA-VAM,
SA-VAM2) and the storage services module (MDS-IPS-8 IP) use the IP Payload Compression Protocol
(IPPCP)/LZS (RFC 2395) algorithm for compressing data.
The LZS compression algorithm works by searching for redundant data strings in the input data stream
and then replaces these strings with data tokens that are shorter in length than the original data. A table
is built of these string matches, pointing to previous data in the input stream. The net result is that future
data is compressed based on previous data. The more redundant the data in the input stream, the better
the compression ratio. Conversely, the more random the data, the worse the compression ratio will be.
The compression history used by LZS is based on a sliding window of the last 2000 bytes of the input
stream. When the data is transmitted, it contains both literal data and compressed tokens. Literal data are
input data streams that cannot be compressed and are transmitted uncompressed. Compressed tokens are
pointer offsets and data length that point to the compression history table. The remote side rebuilds the
data from the compressed history table based on the pointers and length fields.
Note A full description of IPPCP and LZS are available in RFC 2395 and in ANSI X.3241-1994.
Compression Support in Cisco MDS
Both software- and hardware-based compression are supported by the Cisco MDS product line.
Depending on the SAN-OS version and the hardware used, customers can determine which compression
methods apply.
The software-based compression solution is available on the IPS-IP Storage Service Module for the
Cisco MDS 9216/MDS 9216i fabric switch and the Cisco MDS 9500 series storage directors. This
feature is available in SAN-OS version 1.3(2a) and later releases. The software-based compression is
available on each of the eight IPS-8 Gigabit Ethernet ports. The number of Gigabit Ethernet ports used
on the IPS does not affect the performance of the compression with this feature enabled.