Network Working Group E. Stephan Internet Draft France Telecom R&D draft-stephan-ippm-test-packet-header-01.txt October 23, 2002 IPPM measurement signature Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 Despite the growing availability of good measurement platforms, it is still impossible to generalize IPPM metrics measurement among heterogeneous points of measure. To do so, the extra information inserted in the IP packets to perform the measurement has to be standardized. This document defines an IPPM measurement signature suitable for performing the measure of the current IPPM metrics, for integrating those used by manufacturers and for allowing the IPPM WG to define other measurement signature in the future. Stephan Informational - Expires December 2002 [Page 1] Internet Draft IPPM measurement packet June 2002 Table of Contents 1. Introduction................................................2 2. Motivations and Goals.......................................2 3. The IPPM Framework..........................................3 4. Terminology.................................................3 5. State of the art............................................3 6. Requirements................................................5 7. IPPM Measurement signature framework........................7 8. Discussion on IMS and OWAP base formats.....................8 9. IPPM measurement signature formats.........................10 10. Proprietary extension......................................12 11. Software and hardware techniques interoperability..........12 12. Security...................................................12 13. References.................................................13 14. Author's Addresses.........................................13 1. Introduction This document defines an IPPM measurement signature suitable for performing the measure of the current IPPM metrics, for integrating those used by manufacturers and for allowing the IPPM WG to define other measurement signature in the future. 2. Motivations and Goals Despite the growing availability of good measurement platforms, it is still impossible to generalize IPPM metrics measurement among heterogeneous points of measure. To do so, the extra information inserted in the IP packets to perform the measurement has to be standardized. There is a need for interoperability among heterogeneous manufacturer equipments to measure the performance of IP networks for different Type-P. This effort is motivated too by the need to perform end-to-end measures across administrative areas and composite networks. Currently there are only two solutions. The first one consists in the concatenation of end-to-end metrics. As these measures are not performed simultaneously and the test packets metered are different and the accuracy of the concatenation is extremely variable. The second one ICMP use is generalized but does not allow the description of the different Type-P needed in the measurement packets. The standardization of the access to the results of the measure of the metrics defined by the IPPM WG is a 'work in progress'. The proxy mode of the IPPM Reporting MIB provides a system of measure with an Stephan Informational - Expires December 2002 [Page 2] Internet Draft IPPM measurement packet June 2002 exchange point for the results of the measure. One limitation is the incapacity to generalize end-to-end measures. The main reason is the lack of standard measurement packets. This memo analyses the state of the art in the domain, then it defines a framework for the standardization of the measurement packets. Finally it proposes and motivates a definition for a measurement packet signature. 3. The IPPM Framework The IPPM Framework consists in 4 major components: + A general framework for defining performance metrics, described in the Framework for IP Performance Metrics, RFC 2330; + A set of standardized metrics, which conform to this framework. The IPPM Metrics for Measuring Connectivity, RFC 2678 [2]. The One-way Delay Metric for IPPM, RFC 2679 [3]. The One- way Packet Loss Metric for IPPM, RFC 2680 [4]. The Round-trip Delay Metric for IPPM, RFC 2681 [5]; + Emerging metrics which are being specified in respect of this framework; + A Reporting MIB to exchange the results of the measures. It is an interface between a system of measure and the administrative entities interested in these results. This proxy controls the access to the results. These entities use the results to compute statistics and aggregated metrics. 4. Terminology 4.1. IP measurement packet definition A measurement packet is a regular Internet packet that contains additional fields needed for measurement inserted somewhere in the packet. 4.2. IPPM measurement signature definition An IPPM measurement signature is a regular Internet packet that contains a standard block of fields needed for performing IPPM measure. This block of fields is named IPPM measurement signature (IMS). The type of the Internet packet determines the Type-P of the measure. 5. State of the art Stephan Informational - Expires December 2002 [Page 3] Internet Draft IPPM measurement packet June 2002 As Internet is designed for 'best effort' the specifications do not include the control of the quality of service provided. The IPPM WG has started an effort to standardize the protocols for measuring the performance of the network. It encounters 2 main issues. The measurement packets must not be easy to detect by the network equipments and must be easy to detect by measurement tools. The standard solution must be easy to implement and must not be a security hole. This section analyses the existing solutions and extracts the common parts to provide inputs for a first proposal. 5.1. ICMP ICMP if the only test packet that is standardized. There is no doubt that it is dramatically used. On the other hand ICMP has serious limitations. Basically it cannot emulate type-P like UDP or TCP. 5.2. Type-P The Type-P corresponds to the suite of protocols present in the IP and SUB IP headers of the packet. Software based devices inserts the data needed for the measure after the header of the packets. That increases the speed of software processing in the source and in the sink. The additional fields needed for measurement differs according to the Type-P. Typically its contents changes when fields of the packet header are used as data for the measurement. Moreover its location in the packet changes according to the Type-P. That makes it difficult to receive and timestamp the test packets at wire time. This technique is not adapted to high-speed rate. At high-speed rate (e.g. over OC12), hardware based devices insert the data needed for the measure in a fixed block of fields located at the end of the packet. That simplifies dramatically the design because the measurement data are located in the regular part of the packets. It generalizes the concept of Type-P for IPng, SUB IP and permit operational interoperability among heterogeneous SUB IP links. On the receiver's side it facilitates the detection of the test packet at wire speed, the time stamping of the packet on the fly and finally the extraction of the test signature. 5.3. Wire time and time stamping This IPPM framework defines the wire time of a packet inserted on the network as the time that the last bit of the packets is sent. Stephan Informational - Expires December 2002 [Page 4] Internet Draft IPPM measurement packet June 2002 Most of the hardware implementations insert the timestamp on the fly and complement the binary value of the packet in a timestamp complement field. The delay between the timestamp insertion and the packet insertion on the wire is deterministic. The timestamp inserted is increased by the value of this delay while preserving the accuracy of the timestamp. This technique is generalized for link rate over gigabit/s. It is very accurate but requires larger field. Software devices do not share a common technique. The timestamp is inserted at different places, at different time according to the implementation and the operating system. There is not a common technique to adjust the timestamp value. The delay between the timestamp insertion and the packet insertion on the wire is not deterministic and introduces an initial jitter. 6. Requirements 6.1. Existing measurement fields IPPM measurement systems share the same semantic. The information inserted in the packet is very closed. The measurement packets differ only by the fields order, the field name, the field unit, the field size. The common fields are the following: The device that has sent the packet; The interface that has sent the packet; The identifier of the stream the packet belongs to; The absolute timestamp corresponding to the time the packet is sent; The sequence number of the packet; The absolute timestamp corresponding to the time the packet is received; A checksum computed on the previous fields; One-complement of timestamp; 6.2. OWAMP requirements The IPPM WG is standardizing a measurement protocol. The requirements are listed in the "A One-way Active Measurement Protocol Requirements" (draft-ietf-ippm-owdp-reqs-01.txt). The test protocol needs to have the following characteristics: + Be lightweight and easy to implement. + Be suitable for implementation on a wide range of measurement nodes. Stephan Informational - Expires December 2002 [Page 5] Internet Draft IPPM measurement packet June 2002 + Since the protocol needs to be able to measure individual packet delivery time and has to run on various machines, it needs to support UDP as transport protocol. + It should be possible to use varying packet sizes and network services, as negotiated using OWDP-Control. + To be a lowest common denominator, OWDP-Test packet format should only include universally meaningful fields, and minimum number of them. + It should be possible to make packets generated by OWDP-Test as small as possible, to be able to accurately measure paths where packet-splitting technologies such as ATM are used. 6.3. Interoperability requirements The requirement is to have operational interoperability among heterogeneous manufacturers and to perform one-way delay measurement across administrative areas and among composite networks. The constraints to gain inter domain interoperability and interoperability between heterogeneous manufacturers devices does not differ. The meaning of the common fields has to be adapted to the interoperability context. In a test involving heterogeneous equipments the values set up by the source have no meaning for the sink. The meaning of the administrative fields must be set by an entity common to the source and the sink. A field value sets by the source has no meaning for the sink excepted if the value refer to a shared referential. A typical example is the need to create a referential for the time. The issue does not consist only in having the IMS format to be recognized. The main need is to have the results of the measurement packets to be assigned to the same measure setup in the sink and in the source. The measure must be identified in the IMS. It must include a field that identifies the measure in the scope of the initiator of the measure. 6.4. SUB IP and IPNG needs The measurement packet must consider the measure of the performance of multicast services, mobile IP services and Ipv6. The protocol translation mechanisms and the coexistence between Ipv4 and Ipv6 are potential sources of interoperability of the measures. 6.5. Relationship with other organization Stephan Informational - Expires December 2002 [Page 6] Internet Draft IPPM measurement packet June 2002 The aim is to increase operational interoperability. Basically it consists in promoting the need to share the same measurement packets identification mechanism to unambiguously detect the measurements packets and avoid overlapping regarding the fields' values chosen. 7. IPPM Measurement signature framework The aim is to provide a standard signature of the packet to perform measurements of the IPPM metrics across administrative areas and among heterogeneous devices. The framework has the following requirements: + Respects the IPPM Framework requirements (RFC2330) regarding the Type-P and the accuracy; + Respects the requirements for the test protocol of OWAMP; + Specifies a format that allows the integration of the future needs; + Specifies a test packet format for including the IMS in regular packets; + Integrates the existing test packets format and concepts whenever it is possible. The requirements and the needs may be gathered in a strong constraint: to have operational interoperability among heterogeneous manufacturers and to perform one-way delay measurement across administrative areas for the different Type-P, including those that have short packet-length constraints. The basic Type-P are obviously UDP and TCP. 7.1. Measurement packet identification To distinguish measurement packets among regular packets, the last field of the IMS is a protocol identifier. 7.2. RFC2330 Type-P The header of the packet defines the type-P of the test packet from the network point of view. 7.3. RFC2330 Wire time and time stamping There is a strong requirement in the IPPM framework to have a timestamp consistent with the time the packet is inserted on the network. The specification must not increase the complexity of the time stamping at multi gigabit rates. Stephan Informational - Expires December 2002 [Page 7] Internet Draft IPPM measurement packet June 2002 7.4. IPPM measurement signature format It permits the IPPM WG to define several versions of the measurement packets. 7.5. State machine limitation To guaranty operational interoperability the model is stateless excepted for semantic needs such as packet sequence order and security. That does not preclude the definition of more complex test packets in the future. 7.6. Packet sequence number More and more services cross gateways. They may change the sequence numbering of the packets in the header (e.g. the initial value). A lot of metrics computation relies on the analysis of the order of the packets. To provide a trustable sequence of results there is a need for the sequence number to be integrated in the IMS. 7.7. Measure initiator scope The management framework of the IPPM-REPORTING-MIB defines a namespace for each initiator (owner) of a measure. Each measure is identified by its owner and by the number chosen by the initiator for this measure within its scope. These values provides to the source and sink with a shared identifier. This field is mandatory to discriminate concomitant measures set up between 2 points measures. It permits different initiators to set up measures between 2 point of measures while concerning different metrics and Type-P. 8. Discussion on IMS and OWAP base formats Measures performed with a timestamp resolution under the second are out of the scope of this memo. The OWAMP timestamp format reduces the maximal resolution of the NTP timestamp to improve the accuracy of operational measure of performance and to permit an efficient interoperability of the measure. It reuses the MSB of the 'fractional part of the second' field to carry both the source clock precision and the source synchronization state. Its resolution, ~50ns excludes ipdv measures on gigabit networks. As an example, consider the measure of IPDV of small packets (or cells) on the next generation of gigabit link, the 40G. The timeslot of such a packet is closed to 10 nanoseconds (400 bits* 1/40 ns). With such a timer resolution the first variation metered will correspond to 5 times the Stephan Informational - Expires December 2002 [Page 8] Internet Draft IPPM measurement packet June 2002 size of the packet itself. It means that the jitter will be computable only for packet of which the size is over 400 bytes. That excludes most of the real time applications, such as VoIP. The proposed timestamp is respectful of the OWAMP timestamp design while preserving the maximal resolution of the NTP timestamp format. It permits a timestamp resolution suitable for the measure over multi gigabit path. It preserves the NTP timestamp format. It differs because it counts the second since 1 Jan 2000 0H00 instead of 1 Jan 1900 0H00. It will wrap in year 2068 (The NTP timestamp will wrap in year 2036). As it does not count the second of the last century, the most significant bit of the part that represents the second is not needed for counting the second. It is set to indicate if the fractional part of the second contains a precision field. When this bit is not set the resolution is maximal. The maximal resolution is closed to 250 picoseconds (see NTP RFC). The field Prec has the same semantic than in OWAMP. Its definition differs because it counts only the trusted bits of the fractional part of seconds. The field S is 3 bits long to describe the current level of clock synchronization (Status 0 to 7+). The proposal is to define a common packet signature format common to the OWAP test packet and to IMS. It is directly inspired from the 'unauthenticated test packet' defined for the OWDP. This base is enhanced to define different types of IMS and to define the different type of OWAP test packets. It permits top define up to 16 different type and up to 4 versions. Currently that is enough both for IMS and OWAP needs and for the future. It is 12 bytes length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Prec | S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |Ext| Type |Ver| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stephan Informational - Expires December 2002 [Page 9] Internet Draft IPPM measurement packet June 2002 9. IPPM measurement signature formats The field type values are: type=0 : Basic IMS type=1 : Interdomain IMS type=2 : RoundtripDelay IMS type=3 : Interdomain RoundtripDelay IMS type=4 : IMS with Checksum to be continued 9.1. Interdomain 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Owner Id | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Measure Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |Ext| Type |Ver| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.2. RoundtripDelay 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |Ext| Type |Ver| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.3. Interdomain RoundtripDelay 0 1 2 3 Stephan Informational - Expires December 2002 [Page 10] Internet Draft IPPM measurement packet June 2002 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Owner Id | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Measure Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |Ext| Type |Ver| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.4. CHK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHK | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |Ext| Type |Ver| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stephan Informational - Expires December 2002 [Page 11] Internet Draft IPPM measurement packet June 2002 10. Proprietary extension Manufacturers may insert proprietary extension at the beginning of the IMS while preserving measurement interoperability. The field 'Ext' indicates the number of blocks of 8 bytes, which carried proprietary data. Example: An measurement point that need an 5 bytes of extra information to been inserted in an interdomain IMS use the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extra information block | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Owner Id | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Measure Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 1 | 1 |Ver| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11. Software and hardware techniques interoperability Both hardware and software solutions used the header of the packet to define the type-P, insert an IMS in the payload of the packets. They differ on the location of the IMS in the packet. It is obvious that interoperability between software and hardware technique will be reached when they will use the standardized IMS with no extra data in the type-P SDU. The maximum interoperability is gained when the type-P packet PDU consists only of the IMS. 12. Security Stephan Informational - Expires December 2002 [Page 12] Internet Draft IPPM measurement packet June 2002 To avoid the measurements systems to be used to make attacks there is a strong requirement to propose a security mechanism to control the access to the setup of the network measures. From the network security point of view, the main security hole in a network measure is the control test packet. The standardization of a packet signature does not facilitate the control of a probe to perform a DOS attack. 13. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [3] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [5]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay Metric for IPPM.", RFC 2681, September 1999. 14. Author's Addresses Emile STEPHAN France Telecom R & D 2 avenue Pierre Marzin F-22307 Lannion cedex Phone: (+ 33) 2 96 05 11 11 Email: emile.stephan@francetelecom.com Full Copyright Statement "Copyright (C) The Internet Society (2001). 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 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 Stephan Informational - Expires December 2002 [Page 13] Internet Draft IPPM measurement packet June 2002 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. Stephan Informational - Expires December 2002 [Page 14]