Subject: [ipfix] Per-packet record proposal

From: [email-masked]
Date: Thu, 26 Jun 2003 10:50:34 +0900

Dear IPFIXers,

We have read through a set of IPFIX drafts and found that it may be useful
to extend the IPFIX information model, metering process, configuration, and
data export as described in the attached draft.  We provided the rationale
of our proposal and necessary extensions in the document in detail.  We
would highly apprciate your time for reading and commenting it.

We submitted this document as an individual submission but it hasn't been
registered in the IETF internet draft registery yet.  Thus, I attached the
document for your easiler reference.  

Sincerely,

Taesang, Changhoon
ETRI

---

From: "David Diep" <[email-masked]>
Date: Thu, 26 Jun 2003 17:15:54 +0900

Hi,
 
The per-packet information could be used in QoS passive measurement when
the meter needs to export a list of packet identifier (packetID) and the
associated timestamps. In order to reduce the packetID collision a
classical scheme is to generate the packetID based on packet header and
packet payload and then to use CRC-32 function. In the presented
document the pktId type is defined as short type. I think that in order
to be used with a low collision probability as the packetID, the type of
the pktId parameter should be based at least on a 32-bits type.
 
Best Regards,
 
David Diep 
 
-----Original Message-----
From: majordomo listserver [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, June 26, 2003 10:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [ipfix] Per-packet record proposal
 
Dear IPFIXers, 
We have read through a set of IPFIX drafts and found that it may be
useful to extend the IPFIX information model, metering process,
configuration, and data export as described in the attached draft.  We
provided the rationale of our proposal and necessary extensions in the
document in detail.  We would highly apprciate your time for reading and
commenting it.
We submitted this document as an individual submission but it hasn't
been registered in the IETF internet draft registery yet.  Thus, I
attached the document for your easiler reference.  
Sincerely, 
Taesang, Changhoon 
ETRI

---

From: Changhoon Kim <[email-masked]>
Date: Thu, 26 Jun 2003 18:04:54 +0900

Hi David,

Thank you for your interest and comment.

We intended to use the pktId element to contain the 16-bit
identification value in the IP header.
The identification is a host-local value and incremented by one each
time a datagram is sent by the src host.
The field plays an important role for reassemblying packet fragments and
for detecting some routing anomalies;
when two packets within a flow have the same id (with different
timestamps), it guarantees that there exists a routing loop on the
flow's path. We, thus, see that the pktId element should contain the
value of the identification field without additional processing.

If the consensus of the group is turned out to define another element
for identifying every packet in a globally unique way, then we may be
able to add another element for that purpose.

Best,

- Chang

David Diep wrote:

> Hi,
>
> The per-packet information could be used in QoS passive measurement
> when the meter needs to export a list of packet identifier (packetID)
> and the associated timestamps. In order to reduce the packetID
> collision a classical scheme is to generate the packetID based on
> packet header and packet payload and then to use CRC-32 function. In
> the presented document the pktId type is defined as short type. I
> think that in order to be used with a low collision probability as
> the packetID, the type of the pktId parameter should be based at least
> on a 32-bits type.
>
> Best Regards,
>
> David Diep
>
> document in detail.  We would highly apprciate your time for reading
> and commenting it.
>
--
==================================================
Chang H. Kim

Engineer
Internet Traffic Management Team
Electronics and Telecom Research Institute (ETRI)
[email-masked]
http://chang.miner.ne.kr

Office : +82-42-860-5801
Mobile : +82-19-226-6305
Fax : +82-42-860-5440
==================================================
Let's roll!

---

From: "David Diep" <[email-masked]>
Date: Thu, 26 Jun 2003 19:27:56 +0900

Hi Chang,
 
If you use IP header "identification" field for any flow this is
problematic because this value is unique for a "source-destination pair
and protocol for the time the datagram will be active in the internet
system". To my understanding the flow definition of IPFIX is much more
flexible ("This definition covers the range from a flow containing all
packets observed at a network interface to a flow consisting of just a
single packet" from draft-ietf-ipfix-protocol-00.txt). Consequently your
probability of collision may be high depending on the flow type that you
consider so in the general case, you will not be able to conclude
anything about rooting loop in case you have two times the same id for a
given flow.
 
Last point, you're a using an IPv4 specific feature that you can't
extend directly to IPv6 traffic.
 
Regards,
 
David
 
-----Original Message-----
From: majordomo listserver [mailto:[email-masked]] On
Behalf Of Changhoon Kim
Sent: Thursday, June 26, 2003 6:05 PM
To: David Diep
Cc: [email-masked]; [email-masked]
Subject: Re: [ipfix] Per-packet record proposal (pktId)
 
Hi David, 
  
David Diep wrote: 
Hi,

---

From: Changhoon Kim <[email-masked]>
Date: Fri, 27 Jun 2003 15:08:46 +0900

Hi David,

Your point is correct.
However, the purpose of the pktId is not for identifying a packet in a
flow-locally (or globally) unique way,
but conveying the identification value as it is originally marked in the
packet.
If majority of the group view that we need to have another element for
the flow-local identificaion purpose,
defining a new element is always welcomed.

IPv4 specific issues. Yes, I only considered IPv4 while I was writing
the 00 draft.
I also hope that the group will improve the draft so that it reflects
the considerations for IPv6.

Best,

- Chang

> If you use IP header identification field for any flow this is
> problematic because this value is unique for a source-destination pair
> system. To my understanding the flow definition of IPFIX is much more
> flexible (This definition covers the range from a flow containing all
> single packet from draft-ietf-ipfix-protocol-00.txt). Consequently
> your probability of collision may be high depending on the flow type
> that you consider, so in the general case, you will not be able to
> conclude anything about rooting loop in case you have two times the
> same id for a given flow.
> Last point, you're using an IPv4 specific feature that you can't
> extend directly to IPv6 traffic…
>
> Regards,
>
> David
>
> The field plays an important role for reassemblying packet fragments
> and for detecting some routing anomalies;
>> when the meter needs to export a list of packet identifier
>> (packetID) and the associated timestamps. In order to reduce the
>> packetID collision a classical scheme is to generate the packetID
>> based on packet header and packet payload and then to use CRC-32
>> function. In the presented document the pktId type is defined as
>> short type. I think that in order to be used with a low collision
>> probability as the packetID, the type of the pktId parameter should
>> be based at least on a 32-bits type.
>> Best Regards,
>> David Diep
>>

---

From: Tanja Zseby <[email-masked]>
Date: Fri, 27 Jun 2003 12:54:39 +0200

Hi,

we support the idea to integrate a field for a packet ID for multipoint 
QoS measurements.
Maybe you can have a look at a paper that we presented a few month ago 
on how to use IPFIX/netflow9 for passive one-way delay measurements:
http://www.ist-intermon.org/workshop/papers/03_03_powd-netflow9.pdf
We also started a separate draft on this (see attachement, not yet 
submitted) for exporting pktIDs and per packet timestamps with IPFIX .

Regards
Tanja

Changhoon Kim wrote:

> but conveying the identification value as it is originally marked in 
> the packet.
>> problematic because this value is unique for a source-destination 
>> pair and protocol for the time the datagram will be active in the 
>> internet system. To my understanding the flow definition of IPFIX is 
>> much more flexible (This definition covers the range from a flow 
>> containing all packets observed at a network interface to a flow 
>> consisting of just a single packet from 
>> draft-ietf-ipfix-protocol-00.txt). Consequently your probability of 
>> collision may be high depending on the flow type that you consider, 
>> so in the general case, you will not be able to conclude anything 
>> about rooting loop in case you have two times the same id for a given 
>> flow.
>> extend directly to IPv6 traffic...
>>
>> Regards,
>>
>> David
>>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: [email-masked]	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

                                                                         
 Internet Draft                                                  G. Pohl 
 Document: <draft-pohl-pktid-00.txt>                    Fraunhofer FOKUS 
 Expires: January 2004                                           L. Mark 
                                                        Fraunhofer FOKUS 
                                                              C. Schmoll 
                                                        Fraunhofer FOKUS 
                                                                T. Zseby 
                                                        Fraunhofer FOKUS 
                                                              June  2003 

        IPFIX Export of packet information for QoS Meaurements 
  
 Status of this Memo 
  
    This document is an Internet-Draft and is in full conformance 
    with all provisions of Section 10 of 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 obsoleted 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 
     
    This document describes an extension for the IP Flow Information 
    Export (IPFIX) protocol that allows to export packet information 
    for QoS measurements with IPFIX.  
    The main idea is to export two types of records per flow. One 
    type, that consists of the usual flow information plus a unique 
    flow id. And a second type of record, that consists of this flow 
    id and the packet data. The flow id is used to associate the 
    packet data to the corresponding flow. 

 Table of Contents 
  
    1.   Introduction.................................................1 
    2.   Terminology..................................................2 
    3.   General Problem Statement....................................2 
    4.   Export of Packet Ids, Timestamps, and Flow Information.......4 
    5.   Export OWD data..............................................4 
    6.   Export and evaluation considerations.........................5 
    7.   Security Considerations......................................5 
    8.   References...................................................5 
    9.   Author's Addresses...........................................6 
    10.  Full Copyright Statement.....................................6 
  
 1. Introduction 
     
    In the scope of passive QoS Measurements there is often the need 
    to exchange and export measurement data in a finer granularity 
    then per flows. As an example we take passive one-way delay 
    measurement and demonstrate the need for per information export 
  
 Mark, Pohl, Schmoll, Zseby Expires January 2004            [Page 1] 

        IPFIX Export of packet information for QoS Meaurements 

    on a per-packet basis. Instead of exporting flow related 
    information per-packet and introducing a high degree of 
    redundancy we show how packet information and flow information 
    can be efficiently be exported and related. 

 2. Terminology 
  
    Collecting Process 
         The collecting process receives records of flow or packet 
         information. The data is stored for later processing (by 
         the calculation process) 
     
    Exporting Process 
         The exporting processes send flow and packet records to the 
         collecting processes. The records are generated by the 
         measurement process. 
     
    Filtering  
         Filtering selects a subset of packets by applying 
         deterministic functions on parts of the packet content like 
         header fields or parts of the payload. A filtering process 
         needs to process the packet (look at packet header and/or 
         payload) in order to make the selection decision. 
     
    Measurement Device 
         A measurement device has access to at least one observation 
         point. It is hosting at least one measurement process and 
         one export process. 
     
    Metering/Measurement Process  
         The measurement process generates records of packet and 
         flow information. Packets passing the observation point are 
         captured, time stamped, filtered and classified. The 
         measurement process calculates the packet Ids. 
          
    Passive One-Way-Delay Measurement 
         abbreviated: POWD Measurement 
     
    Add text here ;-) 

 3. General Problem Statement 
     
    In [Clai03] the IPFIX working group defined an exporting 
    protocol for measurement data and flow information export. 
     
    The initial purpose of that protocol is to exchange information 
    about network traffic flows. In this scope a flow is defined by 
    a handful of key attributes (source/destination address, 
    source/destination port, Layer3 Protocol Type, TOS/DSCP byte, 
    interface of the flow exporting network element). 
     
    In the initial sense, a flow aggregates a number of packets with 
    common attributes. However, for a number of measurements 
    (metrics) there is a need to export per-packet data. As a case 
    in point we mention passive One-Way-Delay measurements. In order 
    to acquire a path delay this way a couple of measurement points 
    are set up - one at either end of the path under examination. 
    Both measurement points will capture and furniture packets with 
    timestamps and generate an identifier for identifying a packet 
    passing both measurement points. Each measurement point will 
    export its measurement data (trace) to a collecting process 
    where the traces are correlated based on the packet identifiers 
    and timestamps and where finally the delay is calculated as a 
    difference of two timestamps of a packet pair.  
                                                        
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 2] 

        IPFIX Export of packet information for QoS Meaurements 

    It is clear that one could consider a single packet as a special 
    case of a flow. This procedure has consequences that conflict 
    with the efficiency of the exporting procedure. When many 
    packets belong to the same flow, i.e. they share common 
    attributes; these attributes would have to be exported on a per-
    packet basis together with a different packet ID each time 
    although the information is redundant. 
     
    There are cases where it is desirable to keep flow information 
    along with the per-packet information, that is, when analyzing 
    packet characteristics while regarding flows. The upper part of 
    Figure 1 shows both packet data (id and timestamp) and 
    information (source and destination address) that is relevant 
    for the flow of the packet belongs to. Undoubtedly, the flow 
    information introduces a huge amount of redundancy, as it exists 
    for every packet. Figure 1 depicts three packets that affiliate 
    to flow A and one packet that belongs to flow B, respectively. 
    Reducing the redundancy is a known problem in relational data 
    base design. The lower part of Figure 1 shows the idea to 
    separate the flow from packet information. In order to maintain 
    the relation between Packet Properties and Flow Properties we 
    introduce indices (idxA and idxB) for the Flow Properties, these 
    are unique concerning all Flow Property entries. The purpose of 
    the indices is to serve as “primary key” that identifies rows of 
    the Flow Properties. The rows are then referenced by the Packet 
    Properties by using the appropriate index. 

    one packet flows 
    +------+------+------------+---------+ 
    | srcA | dstA | packet id1 | tstamp1 | 
    +------+------+------------+---------+ 
    | srcA | dstA | packet id2 | tstamp2 | 
    +------+------+------------+---------+ 
    | srcB | dstB | packet id3 | tstamp3 | 
    +------+------+------------+---------+ 
    | srcA | dstA | packet id4 | tstamp4 | 
    +------+------+------------+---------+ 
     
            separating flow information and packet information 
            reduces redundancy 
                                  Packet Properties 
                                 +-----+------------+---------+ 
    Flow Properties              >idxA | packet id1 | tstamp1 | 
    +------+------+-----+        +-----+------------+---------+ 
    | srcA | dstA |idxA <        >idxA | packet id2 | tstamp2 | 
    +------+------+-----+        +-----+------------+---------+ 
    | srcB | dstB |idxB <-------->idxB | packet id3 | tstamp3 | 
    +------+------+-----+        +-----+------------+---------+ 
                                 >idxB | packet id4 | tstamp4 | 
                                 +-----+------------+---------+ 
     
             exemplarily, the linkage of one packet (id3) and 
             flow B (srcB, dstB, idxB) is explicitly drawn 

    Figure 1: Flow information and packet information 

    In the following paragraphs we propose how to use IPFIX protocol 
    efficiently for exporting packet flow information and per-packet 
    information for OWD computation. 

 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 3] 

        IPFIX Export of packet information for QoS Meaurements 

 4. Export of Packet Ids, Timestamps, and Flow Information 
     
    The IPFIX protocol is template based as NetFlow version 9. For a 
    complete desciption of features of IPFIX refer to [Clai03]. Only 
    that much, templates define the structure of data to be 
    exported, this includes describing data fields to be exported 
    together with its type and meaning.  
     
    For Measurement Process Results we define two different template 
    records, namely Packet Properties and Flow Properties. 
     
    As indicated in Figure 2, the Flow Properties template defines 
    the attributes for a flow; exemplarily IP source and destination 
    address. The important field is the Flow Index Field. As we will 
    explain the Flow Index will allow packet records to reference 
    flow attributes. The Flow Index is a unique identifier for flow 
    definitions. Subsequent data records (marked as R1 … Rk) define 
    the actual flows. The FlowSet ID should indicate the special 
    case of a Flow Property template. (FlowSet IDs 0 and 1 are 
    already reserved for templates consisting of flow fields or 
    option fields, respectively. However, the Collector must handle 
    Flow Properties templates and their data records slightly 
    different than usually.) 
     
    The format for the information related to a single packet is 
    defined in the Packet Properties template. This information is 
    packet specific and normally not shared between many packets. 
    Otherwise one would rather consider the information as flow 
    related and therefore it has not to be exported for every 
    packet. 
    In the case of passive One-Way-Delay measurement, the Packet 
    Properties template consists of at least Timestamp and Packet 
    ID. Additionally, this template contains a Flow Index field. In 
    packet records, the value of this field will contain one of the 
    unique indices of the flow records exported before. 

    +------------------+      +-------------------+ 
    | Template FlowSet |      | Template FlowSet  |   
    |                  |      |                   |  Description of  
    | Flow Properties  |      | Packet Properties |  exported data           
    +----------+-------+      +----------+--------+                  
    ...........|.........................|.............................    
               |                         |                              
    +----------v-------+      +----------v--------+                          
    | Data FlowSet     |      | Data FlowSet      |  exported data            
    |                  <------+                   |  with references by  
    | Flow Properties  |      | Packet Properties |  means of FlowIndex 
    +------------------+      +-------------------+                  
                        
    Figure 2: Template FlowSet and Data FlowSet dependencies 

 5. Export OWD data 
     
    At the collection point packet records of two measurement points 
    are gathered and correlated by means of the packet ID. The one-
    way delay is then calculated as stated earlier. The resulting 
    delay data records are exported in a similar manner as the 
    packet data have been. Especially, the linkage between delay 
    data and flow information is represented with the discussed Flow 
    Index fields. The OWD properties contain the Packet Pair ID 
    (which is the packet ID of the two contributing packet records), 
    a timestamp (which is the timestamp of the packet passing the 
    reference monitor point) in order to reconstruct a time scale, 
    the calculated delay value, and finally a flow index. 
                                                        
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 4] 

        IPFIX Export of packet information for QoS Meaurements 

 6. Export and evaluation considerations 
     
    In order to use IPFIX protocol for packet and OWD data export we 
    have to prepare several things. We must assign a new FlowSet ID 
    from the range 2 to 255 for the Flow Properties templates. 
     
    We have to introduce new Field Type definitions for 
         Packet ID, Length N, 
         Flow Index, Length 4, 
         Timestamp, Length 8 
     
    The size of the packet ID depends on the used generator function 
    – in the case of a CRC32 the field size would be 4 bytes. The 
    range for the flow indices should be reasonable large. We 
    propose at least a 32-bit value, i.e. 4 bytes. 
     
    We suggest using absolute timestamps with a resolution of 
    nanoseconds and a width of 64-bit (signed). The origin will be 
    Jan.1, 1970 as usual. (The range covers ~292 years. So we 
    provoke a year-2262-Problem…) 
    The value for the one-way delay should be a 32-bit (signed) 
    value, which covers ~2 seconds. 
     
    A collecting instance must store the flow records of Flow 
    Properties together with the Flow Indices. The flow records 
    therefore should be handled like templates. A similar timeout 
    and refresh mechanism as for templates themselves should be used 
    for flow records too (refer to [Clai02]). 
     
    The collector must be able to associate incoming packet records 
    to flow records by matching the contained Flow Indices. 
    For obvious reasons, the exporting process must send the 
    appropriate defining flow records with the unique Flow Indices 
    before it can send packet records that reference flow 
    information by indices. 

 7. Security Considerations 
     
    For the proposed extension of the IPFIX protocol the same 
    security considerations as for the IPFIX protocol apply.  
    Nevertheless, additional privacy issues may be of concern if 
    header or content information can be derived from packet IDs. 
     
    TODO : extend section 

 8. References 
     
    [DuGG03]    Nick Duffield, Albert Greenberg, Matthias 
                 Grossglauser, Jennifer Rexford: A Framework for 
                 Passive Packet Measurement, Internet Draft <draft-
                 ietf-psamp-framework-02.txt>, March 2003 
     
    [DuGr00]    Nick Duffield, Matthias Grossglauser: “Trajectory 
                 Sampling for Direct Traffic Observation”, 
                 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 
                 August 28 - September 1, 2000                      
    [QuZC03]    J. Quittek, et. Al: Requirements for IP Flow 
                 Information Export, Internet Draft <draft-ietf-
                 ipfix-reqs-10.txt>, June 2003 
     
    [GrDM98]    Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, 
                 Jed MARTENS, John G. CLEARY: Nonintrusive and 
                 Accurate Measurement of Unidirectional Delay and 
                                                        
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 5] 

        IPFIX Export of packet information for QoS Meaurements 

                 Delay Variation on the Internet, INET'98, Geneva, 
                 Switzerland, July 21-24, 1998 
     
    [ZsZC01]    T. Zseby, S. Zander, G. Carle: Evalutation of 
                 building blocks for passive one-way-delay 
                 measurements, PAM2001, Amsterdam, April 23-24, 2001 
     
    [TPBC03]    T. Tseby, R. Penno, N. Brownly, B. Claise:  
                 IPFIX Applicability, Internet Draft <draft-ietf-
                 ipfix-as-00.txt>, June 2003 
     
    [Clai03]    Benoit Claise: IPFIX Protocol Specification, 
                 Internet Draft <draft-ietf-ipfix-protocol-00.txt>, 
                 June 2003 
     
 9. Author's Addresses 
     
        Tanja Zseby  
        Fraunhofer Institute for Open Communication Systems  
        Kaiserin-Augusta-Allee 31  
        10589 Berlin  
        Germany  
        Phone: +49-30-34 63 7153  
        Fax:   +49-30-34 53 8153  
        Email: [email-masked] 
     
        Lutz Mark  
        Fraunhofer Institute for Open Communication Systems  
        Kaiserin-Augusta-Allee 31  
        10589 Berlin  
        Germany  
        Phone: +49-30-34 63 7306  
        Fax:   +49-30-34 53 8306  
        Email: [email-masked]  
          
        Guido Pohl  
        Fraunhofer Institute for Open Communication Systems  
        Kaiserin-Augusta-Allee 31  
        10589 Berlin  
        Germany  
        Phone: +49-30-34 63 7164  
        Fax:   +49-30-34 53 8164  
        Email: [email-masked]  
     
        Carsten Schmoll 
        Fraunhofer Institute for Open Communication Systems  
        Kaiserin-Augusta-Allee 31  
        10589 Berlin  
        Germany  
        Phone: +49-30-34 63 7136  
        Fax:   +49-30-34 53 8136  
        Email: [email-masked]  

 10. 
     Full Copyright Statement 
  
    Copyright (C) The Internet Society (2002). 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 
                                                        
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 6] 

        IPFIX Export of packet information for QoS Meaurements 

    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. 

 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 7]