File: rfc2398.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (843 lines) | stat: -rw-r--r-- 24,107 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843






Network Working Group                                          S. Parker
Request for Comments: 2398                                  C. Schmechel
FYI: 33                                           Sun Microsystems, Inc.
Category: Informational                                      August 1998


                Some Testing Tools for TCP Implementors

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1. Introduction

   Available tools for testing TCP implementations are catalogued by
   this memo.  Hopefully disseminating this information will encourage
   those responsible for building and maintaining TCP to make the best
   use of available tests.  The type of testing the tool provides, the
   type of tests it is capable of doing, and its availability is
   enumerated.  This document lists only tools which can evaluate one or
   more TCP implementations, or which can privde some specific results
   which describe or evaluate the TCP being tested. A number of these
   tools produce time-sequence plots, see

   Tim Shepard's thesis [She91] for a general discussion of these plots.

   Each tools is defined as follows:

 Name

   The name associated with the testing tool.

 Category

   One or more categories of tests which the tools are capable of
   providing.  Categories used are: functional correctness, performance,
   stress.  Functional correctness tests how stringent a TCP
   implementation is to the RFC specifications.  Performance tests how







Parker & Schmechel           Informational                      [Page 1]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


   quickly a TCP implementation can send and receive data, etc.  Stress
   tests how a TCP implementation is effected under high load
   conditions.

 Description

   A description of the tools construction, and the implementation
   methodology of the tests.

 Automation

   What steps are required to complete the test?  What human
   intervention is required?

 Availability

   How do you retrieve this tool and get more information about it?

 Required Environment

   Compilers, OS version, etc. required to build and/or run the
   associated tool.

 References

   A list of publications relating to the tool, if any.

2. Tools

2.1.  Dbs

 Author
   Yukio Murayama

 Category
   Performance / Stress

 Description
   Dbs is a tool which allows multiple data transfers to be coordinated,
   and the resulting TCP behavior to be reviewed.  Results are presented
   as ASCII log files.

 Automation
   Command of execution is driven by a script file.







Parker & Schmechel           Informational                      [Page 2]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


 Availability
   See http://www.ai3.net/products/dbs for details of precise OS
   versions supported, and for download of the source code.  Current
   implementation supports BSDI BSD/OS, Linux, mkLinux, SunOS, IRIX,
   Ultrix, NEWS OS, HP-UX. Other environments are likely easy to add.

 Required Environment
   C language compiler, UNIX-style socket API support.

2.2.  Dummynet

 Author
   Luigi Rizzo

 Category
   Functional Correctness / Performance

 Description
   Dummynet is a tool which simulates the presence of finite size
   queues, bandwidth limitations, and communication delays.  Dummynet
   inserts between two layers of the protocol stack (in the current
   implementation between TCP and IP), simulating the above effects in
   an operational system.  This way experiments can be done using real
   protocol implementations and real applications, even running on the
   same host (dummynet also intercepts communications on the loopback
   interface).  Reconfiguration of dummynet parameters (delay, queue
   size, bandwidth) can be done on the fly by using a sysctl call. The
   overhead of dummynet is extremely low.

 Automation
   Requires merging diff files with kernel source code.  Command-line
   driven through the sysctl command to modify kernel variables.

 Availability
   See http://www.iet.unipi.it/~luigi/research.html or e-mail Luigi
   Rizzo (l.rizzo@iet.unipi.it).  Source code is available for FreeBSD
   2.1 and FreeBSD 2.2 (easily adaptable to other BSD-derived systems).

 Required Environment
   C language compiler, BSD-derived system, kernel source code.

 References
   [Riz97]








Parker & Schmechel           Informational                      [Page 3]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


2.3.  Netperf

 Author
   Rick Jones

 Category
   Performance

 Description
   Single connection bandwidth or latency tests for TCP, UDP, and DLPI.
   Includes provisions for CPU utilization measurement.

 Automation
   Requires compilation (K&R C sufficient for all but-DHISTOGRAM, may
   require ANSI C in the future) if starting from source. Execution as
   child of inetd requires editing of /etc/services and /etc/inetd.conf.
   Scripts are provided for a quick look (snapshot_script), bulk
   throughput of TCP and UDP, and latency for TCP and UDP.  It is
   command-line driven.

 Availability
   See http://www.cup.hp.com/netperf/NetperfPage.html or e-mail Rick
   Jones (raj@cup.hp.com). Binaries are available here for HP/UX Irix,
   Solaris, and Win32.

 Required Environment
   C language compiler, POSIX.1, sockets.

2.4.  NIST Net

 Author
   Mark Carson

 Category
   Functional Correctness / Performance

 Description
   NIST Net is a network emulator. The tool is packaged as a Linux
   kernel patch, a kernel module, a set of programming APIs, and
   command-line and X-based user interfaces.

   NIST Net works by turning the system into a "selectively bad" router
   - incoming packets may be delayed, dropped, duplicated, bandwidth-
   constrained, etc.  Packet delays may be fixed or randomly
   distributed, with loadable probability distributions.  Packet loss
   may be uniformly distributed (constant loss probability) or
   congestion-dependent (probability of loss increases with packet queue
   lengths).  Explicit congestion notifications may optionally be sent



Parker & Schmechel           Informational                      [Page 4]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


   in place of congestion-dependent loss.

 Automation
   To control the operation of the emulator, there is an interactive
   user interface, a non-interactive command-line interface, and a set
   of APIs.  Any or all of these may be used in concert.  The
   interactive interface is suitable for simple, spur-of-the-moment
   testing, while the command-line or APIs may be used to create
   scripted, non-interactive tests.

 Availability
   NIST Net is available for public download from the NIST Net web site,
   http://www.antd.nist.gov/itg/nistnet/.  The web site also has
   installation instructions and documentation.

 Required Environment
   NIST Net requires a Linux installtion, with kernel version 2.0.27 -
   2.0.33.  A kernel source tree and build tools are required to build
   and install the NIST Net components.  Building the X interface
   requires a version of XFree86 (Current Version is 3.3.2).  An
   Athena-replacement widget set such as neXtaw
   (http://www.inf.ufrgs.br/~kojima/nextaw/) is also desirable for an
   improved user interface.

   NIST Net should run on any i386-compatible machine capable of running
   Linux, with one or more interfaces.

2.5.  Orchestra

 Author
   Scott Dawson, Farnam Jahanian, and Todd Mitton

 Category
   Functional Correctness / Performance

 Description
   This tool is a library which provides the user with an ability to
   build a protocol layer capable of performing fault injection on
   protocols.  Several fault injection layers have been built using this
   library, one of which has been used to test different vendor
   implementations of TCP. This is accomplished by probing the vendor
   implementation from one machine containing a protocol stack that has
   been instrumented with Orchestra.  A connection is opened from the
   vendor TCP implementation to the machine which has been instrumented.
   Faults may then be injected at the Orchestra side of the connection
   and the vendor TCP's response may be monitored.  The most recent
   version of Orchestra runs inside the X-kernel protocol stack on the
   OSF MK operating system.



Parker & Schmechel           Informational                      [Page 5]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


   When using Orchestra to test a protocol, the fault injection layer is
   placed below the target protocol in the protocol stack.  This can
   either be done on one machine on the network, if protocol stacks on
   the other machines cannot be modified (as in the case of testing
   TCP), or can be done on all machines on the network (as in the case
   of testing a protocol under development).  Once the fault injection
   layer is in the protocol stack, all messages sent by and destined for
   the target protocol pass through it on their way to/from the network.
   The Orchestra fault injection layer can manipulate these messages.
   In particular, it can drop, delay, re-order, duplicate, or modify
   messages.  It can also introduce new messages into the system if
   desired.

   The actions of the Orchestra fault injection layer on each message
   are determined by a script, written in Tcl.  This script is
   interpreted by the fault injection layer when the message enters the
   layer.  The script has access to the header information about the
   message, and can make decisions based on header values.  It can also
   keep information about previous messages, counters, or any other data
   which the script writer deems useful.  Users of Orchestra may also
   define their own actions to be taken on messages, written in C, that
   may be called from the fault injection scripts.

 Automation
   Scripts can be specified either using a graphical user interface
   which generates Tcl, or by writing Tcl directly.  At this time,
   post-analysis of the results of the test must also be performed by
   the user.  Essentially this consists of looking at a packet trace
   that Orchestra generates for (in)correct behavior.  Must compile and
   link fault generated layer with the protocol stack.

 Availability
   See http://www.eecs.umich.edu/RTCL/projects/orchestra/ or e-mail
   Scott Dawson (sdawson@eecs.umich.edu).

 Required Environment OSF MK operating system, or X-kernel like network
   architecture, or adapted to network stack.

 References
   [DJ94], [DJM96a], [DJM96b]











Parker & Schmechel           Informational                      [Page 6]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


2.6.  Packet Shell

 Author
   Steve Parker and Chris Schmechel

 Category
   Functional Correctness / Performance

 Description
   An extensible Tcl/Tk based software toolset for protocol development
   and testing. Tcl (Tool Command Language) is an embeddable scripting
   language and Tk is a graphical user interface toolkit based on Tcl.
   The Packet Shell creates Tcl commands that allow you to create,
   modify, send, and receive packets on networks.  The operations for
   each protocol are supplied by a dynamic linked library called a
   protocol library.  These libraries are silently linked in from a
   special directory when the Packet Shell begins execution. The current
   protocol libraries are: IP, IPv6, IPv6 extensions, ICMP, ICMPv6,
   Ethernet layer, data layer, file layer (snoop and tcpdump support),
   socket layer, TCP, TLI.

   It includes harness, which is a Tk based graphical user interface for
   creating test scripts within the Packet Shell.  It includes tests for
   no initial slow start, and retain out of sequence data as TCP test
   cases mentioned in [PADHV98].

   It includes tcpgraph, which is used with a snoop or tcpdump capture
   file to produce a TCP time-sequence plot using xplot.

 Automation
   Command-line driven through Tcl commands, or graphical user interface
   models are available through the harness format.

 Availability
   See http://playground.sun.com/psh/ or e-mail owner-packet-
   shell@sunroof.eng.sun.com.

 Required Environment

   Solaris 2.4 or higher.  Porting required for other operating systems.











Parker & Schmechel           Informational                      [Page 7]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


2.7.  Tcpanaly

 Author
   Vern Paxson

 Category
   Functional Correctness / Performance

 Description
   This is a tool for automatically analyzing a TCP implementation's
   behavior by inspecting packet traces of the TCP's activity. It does
   so through packet filter traces produced by tcpdump.  It has coded
   within it knowledge of a large number of TCP implementations.  Using
   this, it can determine whether a given trace appears consistent with
   a given implementation, and, if so, exactly why the TCP chose to
   transmit each packet at the time it did.  If a trace is found
   inconsistent with a TCP, tcpanaly either diagnoses a likely
   measurement error present in the trace, or indicates exactly whether
   the activity in the trace deviates from that of the TCP, which can
   greatly aid in determining how the traced implementation behaves.

   Tcpanaly's category is somewhat difficult to classify, since it
   attempts to profile the behavior of an implementation, rather than to
   explicitly test specific correctness or performance issues. However,
   this profile identifies correctness and performance problems.

   Adding new implementations of TCP behavior is possible with tcpanaly
   through the use of C++ classes.

 Automation
   Command-line driven and only the traces of the TCP sending and
   receiving bulk data transfers are needed as input.

 Availability
   Contact Vern Paxson (vern@ee.lbl.gov).

 Required Environment
   C++ compiler.

 References
   [Pax97a]










Parker & Schmechel           Informational                      [Page 8]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


2.8.  Tcptrace

 Author
   Shawn Ostermann

 Category
   Functional Correctness / Performance

 Description
   This is a TCP trace file analysis tool. It reads output trace files
   in the formats of : tcpdump, snoop, etherpeek, and netm.

   For each connection, it keeps track of elapsed time, bytes/segments
   sent and received, retransmissions, round trip times, window
   advertisements, throughput, etc from simple to very detailed output.

   It can also produce three different types of graphs:

   Time Sequence Graph (shows the segments sent and ACKs returned as a
   function of time)

   Instantaneous Throughput (shows the instantaneous, averaged over a
   few segments, throughput of the connection as a function of time).

   Round Trip Times (shows the round trip times for the ACKs as a
   function of time)

 Automation
   Command-line driven, and uses the xplot program to view the graphs.

 Availability
   Source code is available, and Solaris binary along with sample
   traces. See http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html
   or e-mail Shawn Ostermann (ostermann@cs.ohiou.edu).

 Required Environment
   C compiler, Solaris, FreeBSD, NetBSD, HPUX, Linux.














Parker & Schmechel           Informational                      [Page 9]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


2.9.  Tracelook

 Author
   Greg Minshall

 Category
   Functional Correctness / Performance

 Description
   This is a Tcl/Tk program for graphically viewing the contents of
   tcpdump trace files.  When plotting a connection, a user can select
   various variables to be plotted. In each direction of the connection,
   the user can plot the advertised window in each packet, the highest
   sequence number in each packet, the lowest sequence number in each
   packet, and the acknowledgement number in each packet.

 Automation
   Command-line driven with a graphical user interface for the graph.

 Availability
   See http://www.ipsilon.com/~minshall/sw/tracelook/tracelook.html or
   e-mail Greg Minshall (minshall@ipsilon.com).

 Required Environment
   A modern version of awk, and Tcl/Tk (Tk version 3.6 or higher).  The
   program xgraph is required to view the graphs under X11.

2.10.  TReno

 Author
   Matt Mathis and Jamshid Mahdavi

 Category
   Performance

 Description
   This is a TCP throughput measurement tool based on sending UDP or
   ICMP packets in patterns that are controlled at the user-level so
   that their timing reflects what would be sent by a TCP that observes
   proper congestion control (and implements SACK).  This allows it to
   measure throughput independent of the TCP implementation of end hosts
   and serve as a useful platform for prototyping TCP changes.

 Automation
   Command-line driven.  No "server" is required, and it only requires a
   single argument of the machine to run the test to.





Parker & Schmechel           Informational                     [Page 10]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


 Availability
   See http://www.psc.edu/networking/treno_info.html or e-mail Matt
   Mathis (mathis@psc.edu) or Jamshid Mahdavi (mahdavi@psc.edu).

 Required Environment
   C compiler, POSIX.1, raw sockets.

2.11.  Ttcp

 Author
   Unknown

 Category
   Performance

 Description
   Originally written to move files around, ttcp became the classic
   throughput benchmark or load generator, with the addition of support
   for sourcing to/from memory. It can also be used as a traffic
   absorber. It has spawned many variants, recent ones include support
   for UDP, data pattern generation, page alignment, and even alignment
   offset control.

 Automation
   Command-line driven.

 Availability
   See ftp://ftp.arl.mil/pub/ttcp/ or e-mail ARL (ftp@arl.mil) which
   includes the most common variants available.

 Required Environment
   C compiler, BSD sockets.

2.12.  Xplot

 Author
   Tim Shepard

 Category
   Functional Correctness / Performance

 Description
   This is a fairly conventional graphing/plotting tool (xplot itself),
   a script to turn tcpdump output into xplot input, and some sample
   code to generate xplot commands to plot the TCP time-sequence graph).

 Automation
   Command-line driven with a graphical user interface for the plot.



Parker & Schmechel           Informational                     [Page 11]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


 Availability
   See ftp://mercury.lcs.mit.edu/pub/shep/xplot.tar.gz or e-mail Tim
   Shepard (shep@lcs.mit.edu).

 Required Environment
   C compiler, X11.

 References
   [She91]

3. Summary

   This memo lists all TCP tests and testing tools reported to the
   authors as part of TCP Implementer's working group and is not
   exhaustive.  These tools have been verified as available by the
   authors.

4. Security Considerations

   Network analysis tools are improving at a steady pace.  The
   continuing improvement in these tools such as the ones described make
   security concerns significant.

   Some of the tools could be used to create rogue packets or denial-
   of-service attacks against other hosts.  Also, some of the tools
   require changes to the kernel (foreign code) and might require root
   privileges to execute.  So you are trusting code that you have
   fetched from some perhaps untrustworthy remote site.  This code could
   contain malicious code that could present any kind of attack.

   None of the listed tools evaluate security in any way or form.

   There are privacy concerns when grabbing packets from the network in
   that you are now able to read other people's mail, files, etc.  This
   impacts more than just the host running the tool but all traffic
   crossing the host's physical network.

5. References

   [DJ94]    Scott Dawson and Farnam Jahanian, "Probing and Fault
             Injection of Distributed Protocol Implementations",
             University of Michigan Technical Report CSE-TR-217-94, EECS
             Department.

   [DJM96a]  Scott Dawson, Farnam Jahanian, and Todd Mitton, "ORCHESTRA:
             A Fault Injection Environment for Distributed Systems",
             University of Michigan Technical Report CSE-TR-318-96, EECS
             Department.



Parker & Schmechel           Informational                     [Page 12]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


   [DJM96b]  Scott Dawson, Farnam Jahanian, and Todd Mitton,
             "Experiments on Six Commercial TCP Implementations Using a
             Software Fault Injection Tool", University of Michigan
             Technical Report CSE-TR-298-96, EECS Department.

   [Pax97a]  Vern Paxson, "Automated Packet Trace Analysis of TCP
             Implementations", ACM SIGCOMM '97, September 1997, Cannes,
             France.

   [PADHV98] Paxson, V., Allman, M., Dawson, S., Heavens, I., and B.
             Volz, "Known TCP Implementation Problems", Work In
             Progress.

   [Riz97]   Luigi Rizzo, "Dummynet: a simple approach to the evaluation
             of network protocols", ACM Computer Communication Review,
             Vol. 27, N. 1, January 1997, pp.  31-41.

   [She91]   Tim Shepard, "TCP Packet Trace Analysis", MIT Laboratory
             for Computer Science MIT-LCS-TR-494, February, 1991.
































Parker & Schmechel           Informational                     [Page 13]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


6. Authors' Addresses

   Steve Parker
   Sun Microsystems, Inc.
   901 San Antonio Road, UMPK17-202
   Palo Alto, CA 94043
   USA

   Phone: (650) 786-5176
   EMail: sparker@eng.sun.com


   Chris Schmechel
   Sun Microsystems, Inc.
   901 San Antonio Road, UMPK17-202
   Palo Alto, CA, 94043
   USA

   Phone: (650) 786-4053
   EMail: cschmec@eng.sun.com































Parker & Schmechel           Informational                     [Page 14]

RFC 2398        Some Testing Tools for TCP Implementors      August 1998


7.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Parker & Schmechel           Informational                     [Page 15]