Network Working Group Jerry Ash Internet Draft AT&T Attila Bader Expiration Date: December 2004 Ericsson Cornelia Kappler Siemens AG May 2004 QoS-NSLP QSpec Template 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Ash et al. Expires December 2004 [Page 1] Internet Draft QoS-NSLP QSpec Template Abstract This draft describes a QSpec template for the QoS NSIS Signaling Layer Protocol (QoS NSLP) for signaling QoS reservations in the Internet. A QSpec is transported in QoS-NSLP messages and is opaque to QoS NSLP. It contains the QoS Signaling Model (QSM) control information and QoS description parameters. Control information is, for example, a flag that a particular QSM was not understood by one QoS NSLP entity. QoS description parameters are primary input and output parameters of the Resource Management Function. They include immutable descriptions of the traffic for which resources are to be reserved and of the desired QoS. QoS description parameters can also be used for collecting information about resource availability along the path. The QSpec template defines generic parameters that are common to many QSMs. They should be used by all QSMs if applicable. By identifying the generic parameters we aim to ensure interoperability between different QSMs. Table of Contents 1 Introduction ................................................. 3 2 Processing of QSpec .......................................... 4 3 QSpec Template ............................................... 5 3.1 Applicability .............................................. 5 3.2 QSpec Format Overview ...................................... 6 3.3 QSM ID ..................................................... 7 3.4 QSM Specific Control Information ........................... 7 3.5 QoS Description Parameter Types ............................ 8 3.5.1 Traffic Descriptors ...................................... 9 3.5.2 QoS Class ................................................ 10 3.5.3 QoS Characterization ..................................... 11 3.5.4 Excess Treatment ......................................... 11 3.5.5 Priority and Reliability ................................. 11 3.5.6 Monitoring Requirements .................................. 12 4 Security Considerations ...................................... 12 5 Open Issues and Outlook ...................................... 13 6 Acknowledgements ............................................. 13 7 References ................................................... 14 8 Authors' Addresses ........................................... 15 9 Full Copyright Statement ..................................... 16 Ash et al. Expires December 2004 [Page 2] Internet Draft QoS-NSLP QSpec Template 1. Introduction The QoS NSLP establishes and maintains state at nodes along the path of a data flow for the purpose of providing forwarding resources (QoS) for that flow [QOS-SIG]. The design of QoS NSLP is conceptually similar to RSVP [RSVP], and meets the requirements of [NSIS-REQ]. QoS NSLP does not mandate any specific 'QoS Signaling Model' (QSM), i.e. it does not mandate a particular QoS provisioning method or QoS architecture. It should be able to support, for example, IntServ and signaling for DiffServ admission control, and satisfy the need of more complex control planes such as defined in [Q.2630, Y.1541]. Examples of different QSMs for NSIS are specified in [TRQ-QoS-SIG, INTSERV-QoS-SIG, RMD-QoS-SIG]. Note that what we call QSM here is called QoS Model in [QoS-SIG]. We call it QSM to emphasize this work is not about inventing new QoS provisioning methods or QoS architectures. Rather it is about enabling the signaling of existing QoS provisioning methods / architectures with QoS NSLP. Future versions of this ID and [QoS-SIG] will be consolidated. QSM-specific information is carried in the so-called QSpec object, which travels in QoS-NSLP messages. The QSpec is opaque to QoS NSLP, and can have subobjects corresponding to the TSpec, RSpec and AdSpec objects specified in RSVP. This is, the QSpec may contain a traffic characterization (TSpec) and a description of desired QoS (RSpec). It can also collect information about available resources (AdSpec). As opposed to RSVP, however, usage of these subobjects is not bound to particular message types to allow for flexibility. E.g., an object collecting information about desired QoS may travel in any QoS NSLP message, for example a QUERY message or a RESERVE message. The QSpec object contains two types of information: QSM control information and a QoS description. The QoS description contains the aforementioned subobjects for description of traffic, description of desired QoS, and for collecting information about resources and offered QoS. The QSM control information contains information not related to the actual resource management but rather to message processing. Examples of QSM control information are scope of the QSpec or a flag indicating the QSM was not understood by one QoS NSIS entity (QNE). QSM control information must not be confused with the common control information, which is a set of objects traveling in QoS NSLP messages. Whereas QSM control information is specific to the QSpec, common control information is specific to the QoS NSLP message. Ash et al. Expires December 2004 [Page 3] Internet Draft QoS-NSLP QSpec Template A QSM describes QSpec usage in QoS NSLP messages, it defines a set of QoS description and QSM control information parameters for QSpec, and it may restrict the values these parameters can take. This draft provides a template for QSpec, which is needed in order to help defining individual QSMs and in order to promote interoperability between QSMs. In particular, the following parameter types are proposed for QSpec: 1) QSpec ID 2) QSM Control Information 3) QoS Description a) Traffic Descriptors b) QoS Class c) QoS Characterization d) Excess Treatment e) Priority and Reliability f) Service Schedule g) Monitoring Requirements The processing of QSpec is described in more detail in Section 2, it is based on the arguments given in [INTSERV-QOS-SIG]. The proposed QSpec template is given in Section 3, including an applicability statement. 2. Processing of QSpec The model of QoS-NSLP message processing is illustrated in Figure 1. A QoS-NSLP message is interpreted in the common NSLP processing of a QNE as described in [QOS-SIG]. The QSpec, however, is opaque to QoS- NSLP, which means that it is not processed in the common NSLP processing but handed over to the resource management function and QSM-specific NSLP processing. The QSM control information is interpreted and perhaps modified by the QSM-specific NSLP processing, and the QoS description is interpreted and may be modified by the resource management function. Both, QSM-specific NSLP processing and the resource management function, may advise the common NSLP processing on how to proceed with the signaling, e.g. to tear down a preempted reservation. From an implementation point of view, the common NSLP processing is the same in each NSIS capable router, whereas QSM-specific NSLP processing and the resource management function are QSM specific. Note that the QSM-specific NSLP processing box is an addition to the QoS-NSLP processing model of [QoS-SIG] suggested in this document. Details of how QSM-specific Ash et al. Expires December 2004 [Page 4] Internet Draft QoS-NSLP QSpec Template NSLP processing, common NSLP processing and the resource management function collaborate need to be worked out. +---------------+ | Local | |Applications or| |Management (e.g| |for aggregates)| +---------------+ ^ +------------------+ ^ | QSM-specific | V | NSLP Processing | +----------+ +---------+ | | | Resource | | Policy | +------------------+<<<<<<>>>>>>>|Mgmt. Fct.|<<<>>>| Control | | Common NSLP | | | | | | Processing | +----------+ +---------+ | | * ^ +------------------+ * ^ . ^ | * ^ | V . * ^ +----------+ * ^ | NTLP | * ^ |Processing| * V +----------+ * V | | * V ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . . * V Figure 1. Updated Model of QoS-NSLP Processing in a QNE 3. QSpec Template 3.1. Applicability The QSpec template defines a format for the QSpec, as well as a number of generic and optional QSpec parameters. Generic parameters provide a common language for QSM developers to build their QSpecs and are likely to be re-used in several QSMs. This eases comparing different QSpecs and different QSMs - and possibly simplifies mapping of one into another. Thus developers should avoid defining Ash et al. Expires December 2004 [Page 5] Internet Draft QoS-NSLP QSpec Template parameters similar to the generic, standardized ones. A specific QSM may, however, only use a subset or perhaps none of the generic QSpec parameters. For instance, it may only allow the QSpec ID and token bucket to be specified. Furthermore, a QSM may define additional parameters. It is also important to note that QNEs need not support all the generic QSpec parameters. Generic parameters SHOULD be used by QSMs if applicable. Generic parameters SHOULD be understood by any QNE. Optional parameters SHOULD be used by QSMs if applicable, and defining optional parameters facilitates interworking. However, QNEs outside the domain employing a particular QSM cannot be expected to understand the optional parameters. It needs to be investigated whether a minimal set of generic QSpec parameters MUST (rather than SHOULD) be supported in any QNE: this may be important for interoperability of QSMs. For example, QoS NSIS functions at the edge of a domain may have to interpret arriving QSpecs and translate them into QSpecs specific to the local QSM. Such translation is not necessarily a local, bi-lateral function between adjacent domains since QSpecs can be stacked and hence tunnel through domains. The set of QSpec parameters that MUST be supported could be a subset of the generic ones defined here. 3.2. QSpec Format Overview QSpec = As described above, the QSpec object contains the actual resource description (QoS description) as well as QSM control information. Both QoS description and QSM control information may contain mutable and immutable parameters. Mutable parameters can be changed by any QNE, including by QoS NSIS functions along the signaling path, whereas immutable parameters are fixed by the initiating QNE and/or responding QNEs. An example of a mutable parameter is bandwidth available along a path, an example of an immutable parameter is bandwidth desired. = Ash et al. Expires December 2004 [Page 6] Internet Draft QoS-NSLP QSpec Template = Mutable or immutable QoS Description parameters can appear as sub- objects as follows: = = , On the QSpec template level, there is no restriction on how many of these sub-objects a QSpec may carry, nor what type of sub-object is carried in what type of QoS NSLP message. For example, in a receiver-initated reservation scenario, the initiating QNE may send a QUERY carrying a object to probe the available resources on the path, and simultaneously carrying and objects. The responding QNE can re-use the latter objects in the RESERVE message. The QoS NSLP and particularly the QSMs prescribe how the sub-objects in QSpecs are interpreted and used, and therefore restrict this freedom. 3.3. QSM ID The QSM ID allows IANA reservation of QSpec parameter combinations. Generic Parameter: IANA 3.4. QSM Specific Control Information QSM specific control information contains QSM specific control fields and flags. This information is used for QSpec-specific control information and for specific signaling functions not defined in QoS- NSLP. It enables building a new signaling model within a QoS-NSLP signaling frame, see for example [RMD-QoS-SIG]. Generic parameters: - mutable time-to-live field, limiting the scope of QSpec to a maximum number of QoS-NSLP hops. TTL must not be confused with the scope of the QoS NSLP message carrying the QSpec. This scope would be coded Ash et al. Expires December 2004 [Page 7] Internet Draft QoS-NSLP QSpec Template in the common control information, as described above. - mutable flag, indicating the QSM was not understood at least one QNE - mutable parameter, indicating unsuccessful reservation in a QNE - = , , immutable parameter, indicating the desired start time and end time of the service, i.e. when is the service available. This parameter is related to the COMMIT flag suggested in [QOS-NSLP]. Further optional parameter examples are: - Message Type, further specifying the QoS-NSLP message type - Flag indicating bi-directional reservation - Flag indicating severe congestion - Load Sharing, a field indicating load sharing and percent of load that is reserved for the actual flow. (It needs to be investigated whether this field, defined in [RMD-QOS-SIG] is equivalent to the NO_RESOURCE_SHARING flag in [QOS-SIG].) 3.5. QoS Description Parameter Types An overview of QoS description parameter types was already given in Section 1. Some QoS description parameter types are by their nature immutable (e.g. priority), some are mutable (e.g. excess treatment), and some can be both mutable or immutable, e.g. bandwidth. Correspondingly, these latter parameters can appear e.g. in as well as in as needed by the QSM. The following table attempts a (preliminary) mapping of QoS description parameter type on sub-object type. Ash et al. Expires December 2004 [Page 8] Internet Draft QoS-NSLP QSpec Template Characterization> Desired> Traffic Descriptors x x x QoS Class x x QoS Charact. x x Excess Treatment x Prio. and Reliability x Service Schedule x Monitoring Requirements x 3.5.1. Traffic Descriptors These parameters may describe traffic characteristics or desired/available QoS. The complexity of the parameter set depends on the QSM being used. They can be just bandwidth, or, more generally indicate an equivalent resource value describing the resources used by the stream that fulfills a probabilistic QoS criterion. They can indicate a traffic envelope that is an upper bound of the expected traffic. Or they may also contain other packet level descriptors that are needed for call admission control used at the boundary of a domain. Traffic descriptors are used for resource management and traffic conformance testing. Traffic conformance testing can be based on, for example, a token-bucket algorithm as specified in [RFC2210]. Traffic descriptor parameters can be mutable or immutable: They can, for example, immutably appear in or . They can also be mutable in traveling, for example, in a QUERY message that collects resource information along a path. In the coding of a traffic descriptor, a bit is included that says whether a specific instance is mutable or immutable (or perhaps it is sufficient to locate in a specific mutable/immutable sub-object) Traffic descriptors are primary input/output parameters of a resource reservation function and are most probably part of any QSM. Generic mutable/immutable traffic descriptor parameters: a. This is the simplest traffic descriptor. It can be an equivalent bandwidth (or resource unit) value, for example, determined at the boundary of a QoS domain derived from more complex descriptors. Whether the bandwidth is to be interpreted as average or peak Ash et al. Expires December 2004 [Page 9] Internet Draft QoS-NSLP QSpec Template bandwidth is defined in the QSM. (Open issue: this freedom may limit interoperability.) b. = The token bucket is, for example, used by the Guaranteed Load or Controlled Load service defined in [RFC2210], which is in common use. Optional Parameters: For some traffic types a simple token bucket is not an appropriate descriptor and other parameters are needed, for example, for admission control or to calculate an equivalent resource value at the boundary of a resource domain [LEAKY-BUCKET]. a. For example, in order to take into account the voice activity in resource management for real-time voice traffic (e.g. VoIP, AMR coded voice), voice activity has to be signaled in addition to token bucket parameters. Note that ITU [Q.2630], which is used for the UTRAN transport network control plane, also applies such a descriptor for the variable bit rate stringent capability class. b. For example, multiple token buckets may be required, such as in ITU [Q.2630], which defines a tolerant capability class described by a two token-bucket model defining traffic behavior in two different time scales. See also [Y.1541]. 3.5.2. QoS Class An application may like to reserve resources for packets with a particular QoS class, e.g. the DiffServ code point (DSCP) per-hop behavior [DIFFSERV], Y.1541 QoS class [Y.1541], or DiffServ-enabled traffic engineering (DS-TE) class type [DS-TE]. Generic immutable QoS Class Parameters, for example, in : = | | Ash et al. Expires December 2004 [Page 10] Internet Draft QoS-NSLP QSpec Template 3.5.3. QoS Characterization These parameters can, for example, describe the QoS characteristics required by the initiating QNE. In this case they appear mutably in . They may also be used by the QoS NSIS functions to describe what guarantees they are able to offer. In this case they appear immutably in . Generic mutable or immutable QoS Parameters = , , , 3.5.4. Excess Treatment This mutable parameter describes how the network provider will process excess traffic, that is, out-of-profile traffic (in case of binary conformance testing) or n-level traffic (in case of n-level conformance testing). The process takes place after traffic conformance testing, described previously. Excess traffic may be dropped, shaped and/or remarked. The excess treatment parameter is initially set by the initiating QNE, and adjusted as needed by QoS NSIS functions: Generic mutable Excess Treatment parameter: 3.5.5. Priority and Reliability [RFC 3209] specifies setup and holding priority, which are in common use. [RFC 3181] specifies preemption and defending priority, which in the opinion of the authors of this document map to the former set of priorities. Reservation priority is an essential way to differentiate flows for emergency services, ETS, E911, etc., and assign them a higher priority than normal or best-effort priority flows (e.g., High, Normal, Best Effort). Restoration priority specifies the urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort). Generic immutable Priority and Reliability Parameters (immutable): a. b. Ash et al. Expires December 2004 [Page 11] Internet Draft QoS-NSLP QSpec Template c. d. . There has been some debate whether such priority parameters should be generic to all NSLPs, generic to QoS-NSLP, or generic to QSMs, that is, where they should be defined. It is beyond the scope of this document whether the priorities defined here are also useful in other NSLPs. However, we believe in the context of QoS-NSLP that priority is best placed in the QSM and QSpec. The reason is that the resource management function seems to function more efficiently if priority state is held there rather than in common QoS-NSLP processing of messages (see Figure 1). Only the resource management function knows that resources are not sufficient and that it may be necessary to preempt a reservation. If preemption state was associated with QoS- NSLP state rather than with resource management state, the resource management function would need to negotiate with the common QoS-NSLP processing until the two work out what reservation to preempt. Note that although we locate priority parameters with the QSM, the fact that we make them generic parameters could be seen as a recommendation to implement them in all QNEs (see discussion above). 3.5.6. Monitoring Requirements Immutable information required about an ongoing reservation. Generic Parameters: 4. Security Considerations A QoS-NSLP message may also carry one or more policy objects that authenticate and authorize the sender of a QSpec. Hence the policy object may be specific to a QSpec and be bound to it. Moreover, the QoS-NSLP policy object would usually be bound to immutable parameters, unless it, too, is changed along the signaling path. In a future version of this draft, the binding of the policy object and QSpec and the resulting authorization issues need to be investigated. Ash et al. Expires December 2004 [Page 12] Internet Draft QoS-NSLP QSpec Template 5. Open Issues and Outlook a. A detailed discussion of QSM development guidelines needs to be provided. b. A more detailed specification of the generic parameters needs to be given. c. The relationship of common NSLP processing, QSM-specific NSLP processing and resource management function, as well as how their tasks differ needs, to be described more clearly. For example, is the QSpec passed to the QSM-specific NSLP processing first and then to the resource management function? How do QSM-specific NSLP processing and the resource management function influence message processing in common NSLP processing? d. Should/can we request that QNEs MUST support a subset of generic parameters? e. Is it QSM or QoS Model? f. Where is an unknown QSM handled? In the common NSLP processing (e.g. by issuing an error notification) or by the QSM-specific NSLP processing (e.g. by setting the corresponding flag in the QSM control information)? Note that the generic parameters contained in an unknown QSM may still be understood by the QSM-specific processing and the Resource Mangagement Function. Hence it may make sense to process even unknown QSMs. g. How is resource sharing handled, respectively, in the common NSLP processing, QSM-specific NSLP processing and resource management function? h. Need to streamline the QSM control information defined here and the COMMIT flag suggested in [QOS-NSLP]. 6. Acknowledgements The authors would like to thank Robert Hancock and Sven van den Bosch for their helpful suggestions. Ash et al. Expires December 2004 [Page 13] Internet Draft QoS-NSLP QSpec Template 7. References [DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [DS-TE] Le Faucheur, F., et. al., Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, July 2003 [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [E.361] ITU-T Recommendation, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies," May 2003. [INTSERV] Braden, B., et. al., "Integrated Services in the Internet Architecture: an Overview," RFC 1633, June 1994. [INTSERV-QoS-SIG] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS," work in progress. [LEAKY-BUCKET] Butto, M., et. al., "Effectiveness of the Leaky Bucket Policing Mechanism in ATM Networks," IEEE Journal of Selected Areas in Communications, Vol. 9. No. 3. April 1991; Yang, X. "Designing Traffic Profiles for Bursty Internet Traffic," IEEE Global Internet, Taipei, Taiwan, November 2002; Sairamesh, J., Shroff, N., "Limitations and Pitfalls of Leaky Bucket," Proceedings of IEEE ICCCN 94, San Francisco, CA, September 1994. [NSIS-REQ] Brunner, M., et. al., "Requirements for QoS Signaling Protocols", work in progress. [NSIS-FRAMEWORK] Hancock, R., et. al., "Next Steps in Signaling: Framework", work in progress. [RMD-QoS-SIG] A. Bader, et. al., "RMD (Resource Management in Diffserv) QoS-NSLP model", work in progress [RSVP] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," RFC 2205, September 1997. [RSVP-INTSERV] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [TRQ-QoS-SIG] Ash, J., et. al., "NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept," work in progress. [QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service Signaling," work in progress. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services," May 2002. [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling Protocol - Capability Set 3" Sep. 2003 Ash et al. Expires December 2004 [Page 14] Internet Draft QoS-NSLP QSpec Template 8. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Fax: +1-(732)-368-8659 Email: gash@att.com Attila Bader Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u. 1 H-1037 Budapest Hungary EMail: Attila.Bader@ericsson.com Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: + 1 973-236-6700 Fax:+1 973-236-7453 E-mail: cdvorak@att.com Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex FRANCE Phone: +33 1 69 63 41 87 Email: yacine.el_mghazli@alcatel.fr Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany Email: cornelia.kappler@siemens.com Ash et al. Expires December 2004 [Page 15] Internet Draft QoS-NSLP QSpec Template Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands EMail: g.karagiannis@ewi.utwente.nl Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-1571 Fax: +.1 732 368-1192 E-mail: acmorton@att.com Percy Tarapore AT&T Room D1-3D33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4172 E-mail: tarapore@.att.com Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@ericsson.com 9. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 Ash et al. Expires December 2004 [Page 16] Internet Draft QoS-NSLP QSpec Template 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. Ash et al. Expires December 2004 [Page 17]