Internet Draft Dafna Sheinwald
Document: draft-sheinwald-iSCSI-CRC-00.txt Julian Satran
Category: informational IBM
Pat Thaler
Vince Cavanna
Matt Wakeley
Agilent
Memo
iSCSI CRC/Checksum Considerations
Satran, Sheinwald Informational, Expire November 2001 1
iSCSI CRC considerations May 7, 2001
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Cyclic redundancy check (CRC) codes [Peterson] are shortened cyclic
codes used for error detection. A number of CRC codes have been
adopted in standards: ATM, IEC, IEEE, CCITT, IBM-SDLC, and more
[Baich]. The most important expectation from such a code is a very
low probability for undetected errors. The probability of undetected
errors on such codes has been, and still is, subject to extensive
studies that have included both analytical models and simulations.
Those codes have been used extensively in communications and magnetic
recording as they demonstrate good "burst error" detection
capabilities but they are good also in detecting several independent
bit errors. Hardware implementations are very simple and well known
(their simplicity has made them popular with hardware developers for
many years) but algorithms and software for effective implementations
of CRC are now also widely available [Williams].
The probability for undetected errors depends on the polynomial
selected, the error distribution (error model) and the data length.
In this memo, we attempt to give some estimates for the probability
of undetected errors that will facilitate the selection of an error
detection code for iSCSI.
We will also attempt to compare CRCs with other checksum forms
(Fletcher, Adler, weighted checksums) inasmuch as available data will
permit.
Sheinwald, D. Informational , Expire October 2001 2
iSCSI CRC considerations May 7, 2001
Sheinwald, D. Informational , Expire October 2001 3
iSCSI CRC considerations May 7, 2001
1. Error models and goals
We will analyze the code behavior under two conditions:
- noisy channel - burst errors of an average length of n bits
- low noise channel - independent single bit errors
Burst errors are the prevalent natural phenomenon on communication
lines and recording media. The numbers quoted for those revolve
around the BER (bit error rate) but frequently those numbers are
nothing else than a reflection of the Burst Error Rate multiplied by
the average burst length. In field engineering tests 3 numbers are
usually quote together - BER, error-free-seconds and severely-error-
seconds - and this illustrates our point.
Even beyond communication and recording media the effects of errors
will be "bur sty" -(e.g., a memory error will affect more than a
single bit and the total effect will not be very different from the
communication error, software errors while manipulating packets will
have a burst effect). Software errors result also in burst errors.
In addition serial internal interconnects will make this type of
error the most common within machines too.
We analyze also the effects of single independent bit errors - as
those can be cause by some defects.
On burst we will assume an average burst error duration of bd that at
a given transmission rate s will result in an average burst of a =
bd/s bits
(e.g., an average burst duration of 3 ns at 1Gbs gives an average
burst of 3 bits).
For the burst error rate we will take 10^-10 (the numbers quoted for
BER on wired communication channels are between 10^-10 to 10^-12 and
we consider the BER as burst-error-rate*average-burst-length).
Please however keep in mind that if the channel includes wireless
links the error rates can be substantially higher.
For independent single bit errors we will assume a 10^-11 error rate.
As the error detection mechanisms will have to transport large
amounts of data (petabytes=10^16 bits) without errors we will target
very low probabilities for undetected errors for all block lengths
(at 10Gb/s that much data can be sent in less than 2 weeks! on a
single link).
Sheinwald, D. Informational , Expire October 2001 4
iSCSI CRC considerations May 7, 2001
Alternatively, as iSCSI has to perform, efficiently we will require
that the error detection capability of a selected protection
mechanism should be very good at least up to block lengths of 8k
bytes (64kbits).
The error detection capability should keep the probability of
undetected errors at values that would be mean "next-to-impossible".
We recognize however that such attributes are hard to quantify and we
resorted to physics - 10^23 is the Avogadro number while 10^45 is the
number of atoms in the known Universe (or it was many years ago when
we read about it) and those would the bounds of incertitude we could
live with. (10^-23 at worst and 10^-45 if we can afford it). For 8k
blocks the per/bit equivalent would be (10^-28 to 10^-50)
Sheinwald, D. Informational , Expire October 2001 5
iSCSI CRC considerations May 7, 2001
2. Background and literature survey
Each codeword of a binary (n,k) CRC code C consists of n = k+r bits.
The block of r parity bits is computed from the block of k
information bits. The code has a degree r generator polynomial g(x).
The code is linear in the sense that the bitwise addition of any two
codewords yields a codeword.
For the minimal m such that g(x) divides (x^m)-1, either n=m, and the
code C comprises the set D of all the multiplications of g(x) modulo
(x^m)-1, or nPud(C,0.5) for some epsilon not=
0.5 and (2) Pud is not always increasing for 0<=epsilon<=0.5. The
value of what was assumed to be the worst Pud is Pud(C,0.5)=(2^-r) -
(2^-n). This stems from the fact that with epsilon=0.5, all 2^n
received words are equally likely and out of them 2^(n-r)-1 will be
accepted as codewords of no errors, although they are different from
the codeword transmitted.
Wolf [Wolf94j] investigated the CCITT 16-bit polynomial. This is a
code of the family of (shortened codes of) a BCH code of length 2^(r-
1) -1 (r=16 in the CCITT 16-bit case) generated by a polynomial of
the form g(x) =(x+1)p(x) with p(x) being a primitive polynomial of
degree r-1 (=15 in this case). These codes have a BCH design distance
of 4. That is, the minimal distance between any two codewords in the
code is at least 4 bits (which is earned by the fact that the
sequence of powers of alpha, the root of p(x), which are roots of
g(x), includes three consecutive powers:
alpha^0, alpha^1, alpha^2).
Hence, every 3 single bit errors are detectable.
Wolf found that different shortened versions of a given code, of the
same codeword length, perform the same (independent of which specific
indexes are omitted from the original code). He also found that for
the unshortened codes, all primitive polynomials yield codes of the
same performance. But for the shortened versions, the choice of the
primitive polynomial does make a difference. Wolf [Wolf94j found a
primitive polynomial which (when multiplied by x+1) yields a
generating polynomial that outperforms the CCITT one by an order of
magnitude. For 32-bit, he found an example of two polynomials that
differ in their probability of undetected burst of length 33 by 4
orders of magnitude.
It so happens, that for some shortened codes, the minimum distance,
or the distribution of the weights, is better than for others derived
from different unshortened codes.
Baicheva et al [Baicheva] made a comprehensive comparison of
different generating polynomials of degree 16 of the form g(x) =
(x+1)p(x), and of other forms. They computed their Pud for code
Sheinwald, D. Informational , Expire October 2001 7
iSCSI CRC considerations May 7, 2001
lengths up to 1024 bits. They measured their "goodnes" -- if
Pud(C,epsilon) <= Pud(C,0.5) and being "well-behaved" -- if
Pud(C,epsilon) increases with epsilon in the range 0,0.5. The paper
gives a comprehensive table that lists which of the polynomials is
good and which is well-behaved for different length ranges.
For a single burst error, Wolf [Wolf94J] suggested the model of (b:p)
burst -- the errors only occur within a span of b bits, and within
that span, the errors occur randomly, with bit error probability 0 <=
p <= 1.
For p=0.5, which used to be considered the worst case, it is well
known that the probability of undetected one burst error of length b
<= r is 0, of length b=r+1 is 2^-(r-1), and of b > r+1, is 2^-r,
independently of the choice of the primitive polynomial.
With Wolf's definition,
where p can be different than 0.5, indeed it
was found that for a given b there are values of p, different from
0.5 which maximize the probability of undetected (b:p) burst error.
Wolf proved that for a given code, for all b in the range r < b < n,
the conditional probability of undetected error for the (n, n-r)
code, given that a (b:p) burst occurred, is equal to the probability
of undetected errors for the same code (the same generating
polynomial), shortened to block length b, when this shortened code is
used with a binary symmetric channel with channel (sporadic,
independent) bit error probability p.
For the IEEE-802.3 used CRC32, Fujiwara [Fujiwara89] measured the
weights of all words of all shortened versions of the IEEE 802.3 code
of 32 check bits. This code is generated by a primitive polynomial of
degree 32:
g(x) = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 +
x^7 + x^5 + x^4 + x^2 + x + 1 and hence the designed distance of it
is only 3. This distance holds for codes as long as 2^32-1. However,
the frame format of MAC (Media Access Control) of the data link layer
in IEEE 802.3, as well as that of the data link layer for the
Ethernet (1980) forbid lengths exceeding 12,144 bits. Fujiwara only
investigated such bounded lengths. They found that for shortened
versions, the minimum distance was found to be 4 for lengths 4096 to
12,144; 5 for lengths 512 to 2048; and even 15 for lengths 33 through
42.
Fujiwara gives a chart of results of calculations of Pud from which
we can see that for codes of length 12,144 and BSC of epsilon = 10^-5
- 10^-4, Pud= 10^-14 - 10^-13 and for epsilon = 10^-4 - 10^-3,
Pud(512,epsilon) = 10^-15
Sheinwald, D. Informational , Expire October 2001 8
iSCSI CRC considerations May 7, 2001
Pud(1024,epsilon) = 10^-14,
Pud(2048,epsilon) = 10^-13,
Pud(4096,epsilon) = 10^-12 - 10^-11, and
Pud(8192,epsilon) = 10^-10 which is rather close to 2^-32.
[Castagnoli93] extended Fujiwara's technique for efficiently
calculating the minimum distance through the weight distribution of
the dual code and explored a large number of CRC codes with 24 and 32
redundancy bit. They explored several codes built as a multiplication
of several lower degree irreducible polynomials.
In the popular class of (x+1)*deg31-irreducible-polynomial they
explored 47000 polynomials (not all the possible ones - 2*(2^30-
1)/31). The best that they found has d=6 up to block lengths of 5275
and d=4 up to 2^31-1 (bits).
The investigation was done in 1993 with a special purpose processor
By comparison the IEEE-802 code has d=4 up to at least 64,000 bits
and d=3 up to 2^32-1 bits.
CRC32/4 (we will call it CRC32C in the rest of this memo) is
11EDC6F41; IEEE-802 CRC is 104C11DB7
[Stone98] evaluated the performance of CRC (the AAL5 CRC that is the
same as IEEE802) and the TCP and Fletcher checksums on large amounts
of data. The results of this experiment indicate a serious weakness
of the checksums on real-data that stems from the fact that checksums
do not spread the "hot spots" in input data. However, the results
show that Fletcher behaves by a factor of 2 better than the regular
TCP checksum.
Sheinwald, D. Informational , Expire October 2001 9
iSCSI CRC considerations May 7, 2001
3. Probability of undetected errors - burst error
3.1 CRC32C (derivations from [Wolf94j])
Wolf [Wolf94j] found a 32-bit polynomial of the form g(x) = (1+x)p(x)
for which the conditional probability of undetected error, given that
a burst of length 33 occurred, is at most (i.e., maximized over all
possible channel bit error probabilities within the burst) 4 * 10^-
10.
We will now find the probability of undetected error, given that a
burst of length 34 occurred, using the result derived in this paper,
namely that for a given code, for all b in the range 32 < b < n, the
conditional probability of undetected error for the (n, n-32) code,
given that a (b:p) burst occurred, is equal to the probability of
undetected errors for the same code (the same generating polynomial),
shortened to block length b, when this shortened code is used with a
binary symmetric channel with channel (sporadic, independent) bit
error probability p.
The approximation formula for Pud of sporadic errors, if the weights
Ai are distributed binomially, is
Pud(C, epsilon) =~= Sigma[for i=d to n]*((n choose i) / 2^r )*(1-
epsilon)^(n-i) * epsilon^i .
Assuming a very small epsilon, this expression is dominated by i=d.
From [Fujiwara89] we know that for 32-bit CRC, for such small n,
d=15. Thus, when n grows from 33 to 34, we find that the
approximation of Pud grows by 34/19; and when n grows further to 35,
Pud grows by another 35/20. Taking, from Wolf [Wolf94j],
Pud(p*|33) = 4 x 10^{-10}, we have Pud(p*|34) = 7.15 x 10^{-10} and
Pud(p*|35) = 1.25 x 10^{-9}.
For the density function of the burst length, we assume the Rayleigh
density function (the discretization thereof to integer), which is
the density of the absolute values of complex numbers of Gauss
distribution:
f(x) = x / a^2 exp {-x^2 / 2a^2 } , x>0
this density function has a peak at the parameter a, and it decreases
smoothly for growing x.
We take three consecutive bits as the most common burst event once an
error does occur, and thus a=3.
Now, the probability that a burst of length b occurs in a specific
position is the burst error rate, which we estimate as 10^{-10},
times f(b).
Sheinwald, D. Informational , Expire October 2001 10
iSCSI CRC considerations May 7, 2001
Calculating for b=33 we find f(33) = 1.94 x 10^{-26}.
Together, we have that the probability that a burst of length 33
occurred which starts at a specific position is 1.94 x 10^{-36}.
Multiplying this by the probability that this burst error is not
detected, Pud(p*|33), we get that the probability that a burst that
occurred at a specific position is not detected is 7.79 x 10 ^{-46}.
Going again along this path of calculations, this time for b=34 we
find that f(34) = 4.85*10^{-28}. Multiplying by 10^{-10} and by
Pud(p*|34) = 7.15*10^{-10} we get that the probability that a burst
of length 34 that occurred at a specific position is not detected
is 3.46*10^{-47}.
Last, computing for b=35, we get 1*10^{-29} * 10^{-10} * 1.25*10^{-9}
= 1.25*10^{-48}.
It looks like the total can be approximated at 10^-45 within the
bounds of what we are looking for.
When we multiply this by the length of the code (because thus far we
calculated for a specific position) we have 10^-45 * 6.5*10^4 =
6.5*10^-41 as an upper bound on the probability of undetected burst
error for a code of length 8K Bytes.
We now start this whole calculation once again, with initial
probability P(p|33) worse than the best that Wolf [Wolf94j] found.
We will take the worst that he found, which he presented against the
best that he found. For this one, P(p*|33) = 5.1*10^{-6}. We will
thus multiply the end result we obtained before, 10^{-45} by 10^4,
the ratio of the best and the worst of Wolf, and conclude that
We can take 10^{-41} as an upper bound for the probability that a
burst occurred but was not detected by CRC32C.
We can also apply this overestimation for IEEE 802.3.
Comment:
2^{-32} = 2.33*10^{-10}.
3.2 Checksums
Sheinwald, D. Informational , Expire October 2001 11
iSCSI CRC considerations May 7, 2001
4. Probability of undetected errors - independent errors
4.1 CRC (derivations from [Castagnoli93])
In [Castagnoli93] it is reported that for epsilon=10^-6, Pud for a
single bit error, for a code of length 8KB, for both cases, IEEE-
802.3 and CRC32C is 10^{-20}. They also report that CRC32C has
distance 4, and IEEE either 3 or 4 for this code length. From this,
and the minimum distance of the code of this length, we conclude that
with our estimation of epsilon, namely 10^{-11}, we should multiply
the reported result by {10^{-5}}^4 = 10^{-20} for CRC32C, and either
10^{-15} or 10^{-20} for IEEE802.3.
4.2 Checksums
For independent bit errors, Pud of CRC is approximately 12,000 better
than Fletcher, and 22,000 than Adler. For burst errors, by the simple
examples that exist for three consecutive values that can produce an
undetected burst, we take the factor to be at least the same.
If in three consecutive bytes, the error values are x, -2x, x then
the error is undetected. Even for this error pattern only, the
conditional probability of undetected error, assuming a uniform
distribution of data, is 2^-16 = 1.5 * 10^-5. The probability that a
burst of length 3 bytes occurs, is f(24) = 3*10^-14. Together:
4.5*10^-19. Multiplying this by the length of the code, we get close
to 4.5*10^-16, way worse than the vicinity of 10^-40.
The numbers in the table in Section 6 below reflect a more "tolerant"
difference (10*4).
Sheinwald, D. Informational , Expire October 2001 12
iSCSI CRC considerations May 7, 2001
5. Complexity of Hardware Implementation
Comparing the cost of various CRC polynomials, we have used a tool
available at http://www.easics.com/webtools/crctool to implement CRC
generators/checkers for various CRC polynomials. The program gives
either Verilog or VHDL code after specifying a polynomial and the
number of data bits, k, to be handled in one clock cycle. For a
serial implementation, k would be one.
The cost for either one generator or checker is shown in the
following table.
The number of 2-input XOR gates, for an un-optimized implementation,
required for various values of k:
+----------------------------------------------+
| Polynomial | k=32 | k=64 | k=128 |
+----------------------------------------------+
| CCITT-CRC32 | 488 | 740 | 1430 |
+----------------------------------------------+
| IEEE-802 | 872 | 1390 | 2518 |
+----------------------------------------------+
| CRC32Q(Wolf)| 944 | 1444 | 2534 |
+----------------------------------------------+
| CRC32C | 1036 | 1470 | 2490 |
+----------------------------------------------+
After optimizing (sharing terms) and in terms of Cells (4 cells per 2
input AND, 7 cells per 2 input XOR, 3 cells per inverter) the cost
for two candidate polynomials is shown in the following table.
+-----------------------------------+
| Polynomial | k=32 | k=64 |
+-----------------------------------+
| CCITT-CRC32 | 1855 | 3572 |
+-----------------------------------+
| CRC32C | 4784 | 7111 |
+-----------------------------------+
For 32 bit datapath, CCITT-CRC32 requires 40% of the number of cells
that the CRC32C requires. For 64 bit datapath, CCITT-CRC32 requires
50% the number of cells.
Sheinwald, D. Informational , Expire October 2001 13
iSCSI CRC considerations May 7, 2001
The total size of one of our smaller chips is roughly 1 million
cells. The fraction represented by the CRC circuit is less than 1%.
Sheinwald, D. Informational , Expire October 2001 14
iSCSI CRC considerations May 7, 2001
6. Summary and conclusions
The following table is a summary of the error detection capabilities
of the different codes analyzed. I the table d is the minimal
distance at block length block (in bits), i/byte - software
instructions/byte, Table size (if table lookup needed), T-look number
of lookups/byte, Pudb - Pud burst and Puds - Pud sporadic:
+-----------------------------------------------------------+
| Code |d| Block |i/Byte|Tsize|T-look| Pudb | Puds |
+-----------------------------------------------------------+
| Fletcher32|3| 2^19 | 2 | - | - | 10^-37 | 10^-36 |
+-----------------------------------------------------------+
| Adler32 |3| 2^19 | 3 | - | - | 10^-36 | 10^-35 |
+-----------------------------------------------------------+
| IEEE-802 |3| 2^16 | 2.75 | 2^18| 0.5/b| 10^-41 | 10^-40 |
+-----------------------------------------------------------+
| CRC32C |3| 2^31-1| 2.75 | 2^18| 0.5/b| 10^-41 | 10^-40 |
+-----------------------------------------------------------+
The probabilities for undetected errors in the above table are
computed assuming uniformly distributed data. For real data - that
can be biased - [Stone98] checksums behave substantially worse than
CRCs
Considering the protection level it offers, the lack of sensitivity
for biased data and the large block it can protect we think that
CRC32C is a good choice as a basic error detection mechanism for
iSCSI.
Please observe also that burst errors that are characterized by a
fixed average time will have higher impact on error detection
capability as the speed of the channels (machines and networks)
increases. The only long-term way to keep the Pud within bounds is to
reduce the BER by using better channel coding (as opposed to source
coding we where dealing with here).
Sheinwald, D. Informational , Expire October 2001 15
iSCSI CRC considerations May 7, 2001
7. References and Bibliography
[Arazi] B Arazi A commonsense Approach to the Theory of Error
Correcting codes
[Baicheva]T Baicheva, S Dodunekov and P Kazakov. Undetected
error probability performance of cyclic redundancy-check codes
of 16-bit redundancy. IEEE Proceedings on Communications,
147:253-256, October 2000
[Black] "Fast CRC32 in Software" by Richard Black, 1994, at
www.cl.cam.ac.uk/Research/SRG/bluebook/21/crc/crc.html
[Castagnoli93] Guy Castagnoli, Stefan Braeuer and Martin
Herrman "Optimization of Cyclic Redundancy-Check Codes with 24
and 32 Parity Bits", IEEE Transact. on Communications, Vol. 41,
No. 6, June 1993
[FITS] "NASA FITS documents" at
http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/docs/general/che
cksum/node26.html
[Fujiwara89] Toru Fujiwara, Tadao Kasami, and Shu Lin. “Error
detecting capabilities of the shortened hamming codes adopted
for error detection in IEEE standard 802.3". IEEE Transactions
on Communications, COM-37:986–989, September 1989.
[Peterson]W Wesley Peterson & E J Weldon - Error Correcting
Codes - First Edition 1961/Second Edition 1972
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996.
[Polynomials] "Information on Primitive and Irreducible
Polynomials" at
http://www.theory.csc.uvic.ca/~cos/inf/neck/PolyInfo.html
[RFC1146] TCP Alternate Checksum Options
[RFC1950] ZLIB Compressed Data Format Specification version 3.3
[Stone98] J. Stone et. al "Performance of Checksums and CRC's
over Real Data" IEEE/ACM Transactions on Networking, Vol. 6,
No. 5, October 1998
[Williams] Ross Williams - A PAINLESS GUIDE TO CRC ERROR
DETECTION ALGORITHMS widely available on the net - (e.g.,
ftp.adelaide.edu.au/pub/rocksoft/crc_v3.txt)
[Wolf82] J.K. Wolf, Arnold Michelson and Allen Levesque. On the
probability of undetected error for linear block codes. IEEE
Transactions on Communications, COM-30:317-324, 1982
[Wolf88] J.K. Wolf, R.D. Blackeney An Exact Evaluation of the
Probability of Undetected Error for Certain Shortened Binary
CRC Codes - Proc. MILCOM - IEEE 1988
[Wolf94J] J.K. Wolf and Dexter Chun The single burst error
detection performance of binary cyclic codes. IEEE Transactions
on Communications COM-42:11-13, January 1994
Sheinwald, D. Informational , Expire October 2001 16
iSCSI CRC considerations May 7, 2001
[Wolf94O] Dexter Chun and J.K. Wolf. Special Hardware for
computing the probability of undetected error for certain
binary crc codes and test results. IEEE Transactions on
Communications, COM-42:2769-2772
Sheinwald, D. Informational , Expire October 2001 17
iSCSI CRC considerations May 7, 2001
8. Author's Addresses
Julian Satran
Dafna Sheinwald
IBM, Haifa Research Lab
MATAM - Advanced Technology Center
Haifa 31905, Israel
Pat Thaler
Vince Cavanna
Matt Wakeley
Agilent Technologies
1101 Creekside Ridge Drive
Suite 100, M/S RH21
Roseville, CA 95661
Sheinwald, D. Informational , Expire October 2001 18
iSCSI CRC considerations May 7, 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Sheinwald, D. Informational , Expire October 2001 19