NSIS Working Group Attila Bader INTERNET-DRAFT Lars Westberg Ericsson Expires: January 2005 Georgios Karagiannis University of Twente Cornelia Kappler Siemens Tom Phelan Sonus July 10, 2004 Resource Management In Diffserv: An NSIS QoS Signaling Model for Diffserv Networks Status of this memo 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 Resource Management in Diffserv (RMD) is a technique for adding admission control to Differentiated Services (Diffserv) networks. RMD complements the Diffserv architecture by pushing complex classification, conditioning and admission control functions to the edges of a Diffserv domain and simplifying the operation of internal nodes. It allows feedback to systems outside of the Diffserv domain on the availability of resources for individual flows within the domain while aggregating end-to-end resource reservations at the edge of the domain to reduce the burden on internal nodes. Bader, et al. [Page 1] INTERNET-DRAFT RMD QoS signaling model This document describes the RMD concept and an NSIS QoS Signaling Model for RMD. The RMD QoS Signaling Model allows devices to use the NSIS QoS-NSLP protocol to signal reservation requests from devices outside the Diffserv domain to edge nodes in the domain, edge nodes to aggregate the requests and signal the aggregated requests through internal nodes along the data path to the egress edge nodes, and for egress edge nodes to signal the original, disaggregated, requests to outside devices. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 3. Overview of RMD QoS Model and QoS Signaling Model . . . . . .4 3.1 RMD QoS Model . . . . . . . . . . . . . . . . . . . . . .4 3.2 RMD QoS Signaling Model Overview . . . . . . . . . . . . 5 4. RMD QoS Signaling Model detailed description . . . . . . . . 6 4.1 Role of QoS NSLP Entities (QNEs) . . . . . . . . . . . . 6 4.2 QSpec Definition . . . . . . . . . . . . . . . . . . . . 6 4.2.1 RMD QoS descriptors . . . . . . . . . . . . . . . .7 4.2.2 RMD control information . . . . . . . . . . . . . .7 4.2.3 Mapping of QSpec parameters onto generic QSpec Parameters . . . . . . . . . . . . . . . . . 8 4.3 Message format . . . . . . . . . . . . . . . . . . . . . 8 4.4 State management . . . . . . . . . . . . . . . . . . . . 8 4.5 Operation and sequence of events . . . . . . . . . . . . 8 4.5.1 Edge discovery and addressing of messages . . . . .9 4.5.2 Basic unidirectional operation . . . . . . . . . . 9 4.5.2.1 Successful reservation. . . . . . . . . . . . 9 4.5.2.2 Unsuccessful reservation . . . . . . . . . . .9 4.5.2.3 Severe congestion. . . . . . . . . . . . . . .9 4.5.3 Basic bidirectional operation . . . . . . . . . . 10 5. Security Consideration. . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .10 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .10 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .11 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Appendix: QoS models, QoS Signaling Models and Qspecs . . .12 Bader, et al. [Page 2] INTERNET-DRAFT RMD QoS signaling model 1. Introduction The Differentiated Services (Diffserv) architecture ([RFC2475], [RFC2638]) was introduced as a result of efforts to avoid the scalability and complexity problems of Intserv [RFC1633]. Scalability is achieved by offering services on an aggregate basis rather than per-flow and by forcing as much of the per-flow state as possible to the edges of the network. The service differentiation is achieved using the Differentiated Services (DS) field in the IP header and the Per-Hop Behavior (PHB) as main building blocks. Packets are handled at each node according to the PHB indicated by the DS field in the message header. The Diffserv architecture does not specify any way for devices outside the domain to dynamically reserve resources or receive indications of network resource availability. In practice, service providers rely on subscription-time Service Level Agreements (SLAs) that statically define the parameters of the traffic that will be accepted from a customer. In [RMD], RMD was introduced as a possible method for dynamic reservation of resources within a Diffserv domain. It describes a method for aggregating individual reservation request at the ingress edge of the domain, two possible modes of operation for internal nodes to admit aggregated requests (a stateless, measurement-based mode, and a reduced-state reservation mode), and a method to forward the original requests across the domain to the egress edge and on. This document describes the RMD concept and specifies a data-path- coupled NSIS QoS Signaling Model that defines how the path-coupled signaling provided by the NSIS QoS-NSLP (Next Steps In Signaling Quality of Service û NSIS Signaling Layer Protocol) can be used to support RMD. The RMD QoS Signaling Model uses the QoS-NSLP [QoS- NSLP] and the NTLP (NSIS Transport Layer Protocol) [NTLP] that are being standardized by the NSIS working group. The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) establishes and maintains states at nodes along the path of a data flow for the purpose of providing or querying forwarding resources for that flow [QoS-NSLP]. In QoS-NSLP the signaling is independent of the underlying QoS model; it can signal for any QoS provisioning method or QoS architecture, such as Diffserv [RFC2475] or IntServ [RFC1633]. The method by which the protocol signals for a specific QoS Model is called QoS Signaling Model. A QoS Signaling Model defines specific QSpec objects, which are carried in QoS-NSLP messages. QSpec objects include QoS descriptors and control information. A QoS Signaling Model also describes how QSpecs are processed. More information on QoS Models, QoS signaling models and QSpec is provided in the Appendix. Bader, et al. [Page 3] INTERNET-DRAFT RMD QoS signaling model In the RMD QoS signaling model, the edges of the Diffserv domain support both the NSIS stateful and stateless/reduced state operations, while the interior routers in the Diffserv domain support only the NSIS stateless/reduced state operation. Only routers at the edges of a Diffserv domain support the QoS-NSLP stateful operation. Internal routers support either the QoS-NSLP stateless operation, or a reduced-state operation with coarser granularity than the edge nodes (e.g., per PHB). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Overview of RMD QoS Model and QoS Signaling Model 3.1. RMD QoS Model The dynamic Diffserv QoS signaling model can be realized by using the original concept of Resource Management in Diffserv (RMD) framework [RMD]. In RMD, scalability is achieved by separating a complex reservation mechanism used in edge nodes of a Diffserv domain from a much simpler reservation mechanism needed in the interior nodes. In particular, it is assumed that edge nodes of a Diffserv domain support per-flow QoS states in order to provide QoS guarantees for each flow. Interior nodes use only one aggregated reservation state per traffic class or no states at all. This solution allows fast processing of signaling messages and makes possible to handle large number of flows in the interior nodes. In this way, the RMD concept optimizes the NSLP/NTLP functionality and processing. In RMD two basic operation modes are described: a measurement based admission control and a reservation based admission control. The measurement-based algorithm uses the requested and available resources as input to query the aggregated reservation state per traffic class in the interior nodes. The advantage of measurement based resource management protocols is that they do not require explicit reservation or release. Moreover, when the user traffic is variable, measurement based admission control could provide higher network utilization than, e.g., peak-rate reservation. However, this requires more complex implementation in interior nodes and introduces an uncertainty of the availability of the resources. In case of the reservation-based method, each node in the domain maintains one reservation state per traffic class. The reservation is done in resource units. These resources are requested dynamically per PHB and reserved on demand in all nodes in the communication path from an ingress node to an egress node. Bader, et al. [Page 4] INTERNET-DRAFT RMD QoS signaling model 3.2. RMD QoS Signaling Model Overview We denote the dynamic Diffserv QoS signaling model, which is based on the RMD concept, the RMD QoS signaling model. The RMD QoS signaling model supports both measurement- and reservation-based admission control. In the first case QoS-NSLP states do not need to be refreshed, therefore it is a stateless operation mode, while the reservation based methods is a reduced state operation mode. The RMD QoS Signaling Model uses a simple, hop-by-hop signaling mechanism. When a new flow arrives with some requested resources (typically bandwidth), a message indicating the required resources is sent along the data path. Every node, one after the other, checks the available resources on the data path of the flow with either the reservation-based or the measurement-based method. If an intermediate node cannot accommodate the new request, it indicates it by marking a single bit in the message. In the simplest case the domain wherein the RMD QoS signaling model is applied is identical to a Diffserv administrative domain. However, the protocol can be extended for multiple domain as well. The boundary nodes of the domain are NSIS aware edge nodes (QNF ingress and QNF egress edges) and the interior nodes are NSIS aware interior nodes (QNF interior). The RMD QoS Signaling Model uses the stateless/reduced state operation mode defined in QoS-NSLP. |------| |-------| |------| |------| | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | | QoS | | QoS | | QoS | | QoS | | | |-------| |------| |------| | | |-------| |-------| |-------| |------| | | | | | local |<->| local |<->| local |<->| local| | | | | | QoS | | QoS | | QoS | | QoS | | | | | | | | | | | | | | | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| | | | | |red.st.| |red.st.| | | | | | | |-------| |-------| |-------| |------| | | |------| |-------| |-------| |-------| |------| |------| ------------------------------------------------------------------ |------| |-------| |-------| |-------| |------| |------| | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| |------| |-------| |-------| |-------| |------| |------| QNI QNF QNF QNF QNF QNR (end) (ingress edge)(interior) (interior) (egress edge) (end) st.ful: statefull, st.less: stateless st.less red.st.: stateless or reduced state Figure 1 Protocol model of stateless/reduced state operation Bader, et al. [Page 5] INTERNET-DRAFT RMD QoS signaling model The protocol model of the RMD QoS Signaling Model is shown in Figure 1. Consider an end-to-end QoS signaling model, i.e., Intserv, in which NF nodes between End and Edge nodes install and maintain per-flow QoS-NSLP states. In the Edge node of the Diffserv domain, the end-to-end QoS-NSLP messages trigger the generation of local dynamic Diffserv QoS-NSLP messages. The QSpec of the end-to-end QoS-NSLP message is translated into RMD QSpec. The original QoS-NSLP messages are sent directly to the next NTLP stateful node, e.g. to the egress edge node. The local QoS-NSLP messages are processed and interpreted in all interior NSLP routers along the path, hop-by-hop, up to the egress edge node. 4. RMD QoS Signaling Model detailed description This section describes the RMD QoS signaling model in details. Particularly, we explain the role of stateless and reduced-state QNEs, define the QSpec Object, the format of QoS NSLP messages, how QSpecs are processed and used, and the protocol operation. 4.1. Role of QoS NSLP Entities (QNEs) Edge nodes of an RMD domain can support both NSIS operation modes, i.e., stateful and stateless/reduced state operation modes. As NSIS stateful nodes the edge nodes can store and administrate QoS- NSLP and NTLP states. The interior nodes are either completely stateless, i.e., they are not supporting any QoS-NSLP or NTLP states as for measurement-based operation, or they are reduced state nodes, i.e., they do not store NTLP states but they store per PHB aggregated QoS-NSLP states as in reservation-based operation. Note that the RMD domain may contain interior nodes that are not NSIS aware nodes. Furthermore, some of these NSIS unaware nodes may be used for measuring the traffic congestion level on the data path. These measurements, however, can be used by the RMD QoS signaling model in the severe congestion operation (see Section 4.5.2.3). 4.2. Qspec Definition This section describes the Qspec that is used by the RMD QoS signaling model. There are two types of QSpec parameters: QoS Descriptors, and Control Information. RMD QSpec parameters are defined in [RMD], and will be updated in line with QSpec Template draft [QSM-T]. Bader, et al. [Page 6] INTERNET-DRAFT RMD QoS signaling model 4.2.1. RMD QoS descriptors : This parameter specifies the resources to be reserved in the nodes along the data path. It can be number of resource units or bandwidth. Bandwidth can be peak bandwidth, average bandwidth or even effective bandwidth, depending on the implementation. The default interpretation of this field is peak bandwidth. : This parameter specifies the traffic class for which resources should be reserved Both these QoS descriptors are immutable and of the type "QoS desired". 4.2.2. RMD control information : In case of unsuccessful reservation in an interior QNF, this QNF sets the M bit in order to notify the egress QNF. : The Hop Count is set to zero when a RESERVE message enters a domain and increased by one at each interior QNF. However when a QNF is reached that does not have sufficient resources to admit the reservation, the M Bit is set, and the Hop Count value is frozen. Hence the Hop Count counts the number of hops where the reservation was successful. In case of an unsuccessful reservation the M Bit is set, and the egress QNF reacts by sending a RESPONSE message containing the Hop Count to the ingress QNF. The ingress QNF uses the Hop Count value to remove the unnecessary reservations by an explicit tearing RESERVE message to the nodes along the path where the reservation has already been made. : In case of a route change refreshing RESERVE messages follow the new data path, and hence resources are requested there. However, on the new path resources may not be sufficient to accommodate the new traffic. Congested interior nodes should notify edge QNFs about the congestion, in order to terminate some of the flows. The notification of the egress QNF is carried out by marking either the data packets with dedicated DSCPs or by setting the S Bit indicating severe congestion in the refresh message. The egress QNF decides which flows should be terminated and sends a Response message to the Ingress edge with the flow ID and indicating the severe congestion. Since refresh messages are usually sent less frequently than the data packets a more efficient method for the notification is marking the data packets by changing the DSCP field. Bader, et al. [Page 7] INTERNET-DRAFT RMD QoS signaling model More details on the required control information for the RMD QoS signaling model will be provided in a future version of this draft. 4.2.3. Mapping of QSpec parameters onto generic QSpec Parameters To be provided in a future version of this draft. 4.3. Message format The format of the messages used by the RMD QoS signaling model complies with the QoS-NSLP specification. As specified in [QoS- NSLP], for each QoS-NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. The BNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation should create messages with the objects in the order shown here, but accept the objects in any permissible order. More details on the message formats will be provided in the future versions of this draft. 4.4. State management The way of how the QoS-NSLP states are created and managed is specified in [QoS-NSLP]. This section will describe how the reservation states Resource Management Function of the reduced states nodes are created and maintained. More details on the state management in the reduced state will be provided in the future. 4.5. Operation and sequence of events This section describes the operation and the sequence of events in the RMD QoS signaling model. More details on the operation and the sequence of events will be provided in future versions of this draft. This operation is similar to the protocol operation described in [RMD]. The transport characteristics for the 'local' reservation model can be different from that of the end-to-end reservation model. GIMPS can be used in a different way for the edge-to-edge and hop-by-hop sessions, (i.e. sending of messages in datagram mode, and not retaining optional path state, i.e., NTLP stateless mode). The reduced state reservation can be updated independently of the per-flow end-to-end reservations. Bader, et al. [Page 8] INTERNET-DRAFT RMD QoS signaling model 4.5.1. Edge discovery and addressing of messages This section describes the egress edge discovery and the addressing of the signaling messages. Mainly, the egress edge discovery can be performed either by using the NTLP discovery mechanism or by configuration. The addressing of signaling messages depends on the used NTLP transport mode. The RMD QoS signaling messages that are processed only by the edge nodes use the peer-peer addressing of the NTLP connection mode (C). While the RMD QoS signaling messages that are processed by all nodes of the Diffserv domain, i.e., edges and interior nodes, use the end-end addressing of the NTLP datagram (D) mode. More details on the egress edge discovery and the addressing of the signaling messages will be provided in a future version of this draft. 4.5.2. Basic unidirectional operation This section describes the basic unidirectional operation and sequence of events of the RMD QoS signaling model. The following basic operation cases are distinguished, more details can be found in [RMD]. 4.5.2.1. Successful reservation This section describes the operation of the RMD QoS signaling model where a reservation is successfully accomplished. 4.5.2.2. Unsuccessful reservation This section describes the operation where a request for reservation cannot be satisfied by the RMD QoS signaling model. 4.5.2.3. Severe congestion This section describes the operation of the RMD QoS signaling model where a severe congestion occurs within the Diffserv domain. Severe congestion is an undesirable event, e.g after re-routing, where the resources are not enough to meet the required QoS for all the flows along the new path, therefore one or more flows should be terminated. Interior nodes notify edge nodes by data marking or marking the refresh messages. In order to eliminate severe congestion the degree of overload can also be indicated, e.g. by using proportional marking. Bader, et al. [Page 9] INTERNET-DRAFT RMD QoS signaling model Congestion can also occur in an interior node due to the underestimation of the data traffic, inappropriate policer settings, or due to the uncertainty introduced by the measurement method. Severe congestion function of RMD can be used for implementiong a lightweight measurement based admission control within a Diffserv domain. It is possible that not all the nodes along the path implement and run admission control, only a few interior nodes are responsible for admission control. In these nodes there may be predefined thresholds that can be set for the different PHBs. If the threshold is exceeded refresh messages or the data packets can be marked to indicate the high load of different PHBs. 4.5.3. Basic bidirectional operation This section describes the basic bidirectional operation and sequence of events in the RMD QoS signaling model. Combined sender-receiver initiated reservation cannot be done in the domain because upstream NTLP states are not stored in interior routers. Therefore bi-directional operation can be performed by two sender- initiated reservations. However, if the edge nodes are common for both upstream and downstream direcrions, RMD offers significant optimization. More details will be provided in the next version of this draft. 5. Security Consideration Future versions of this draft will describe the security considerations associated with the RMD QoS signaling model. 6. IANA Considerations If the document creates a new IANA registry, or reserves new values for an existing IANA registry, an IANA considerations section should be included, see RFC 2434. 7. Open issues This section describes the open issues related to the RMD QoS signaling model. More details on open issues will be provided in a future version of this draft. Bader, et al. [Page 10] INTERNET-DRAFT RMD QoS signaling model 8. Acknowledgments The authors express their acknowledgement to people worked earlier on the RMD concept: Z. Turanyi, R. Szabo, A. Csaszar, A. Takacs, G. Pongracz, O. Pop, V. Rexhepi, D. Partain, M. Jacobsson, S. Oosthoek, P. Wallentin. 9. Authors' Addresses Attila Bader Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u. 1 H-1037 Budapest Hungary EMail: Attila.Bader@ericsson.com Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@ericsson.com Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands EMail: g.karagiannis@ewi.utwente.nl Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany Email: cornelia.kappler@siemens.com Tom Phelan Sonus Networks EMail: tphelan@sonusnet.com Bader, et al. [Page 11] INTERNET-DRAFT RMD QoS signaling model 10. References [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998 [RFC2638] Nichols K., Jacobson V., Zhang L. "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999 [RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in the Internet Architecture: an Overview" RFC 1633 [QoS-NSLP] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004. [QSM-T] Ash, J., Bader, A., Kappler C., "QoS-NSLP QSpec Template" draft-ash-nsis-nslp-QSpec-00 (work in progress), February 2004. [RMD] Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP model", draft-bader-rmd-qos-model-00 (work in progress), February 2004. [QSM-CL] Kappler, C. "A QoS Model for signaling IntServ Controlled- Load Service with NSIS", draft-kappler-nsis-qosmodel- controlledload-00 (work in progress), February 2004. 11. Appendix: QoS models, QoS Signaling Models and QSpecs This section gives a description of QoS models, QSMs and QSpecs and explains what is the relation between them. Once these descriptions are contained in a stable form in the appropriate IDs (mainly QoS NSLP [2] and QSpec Template[3]) this Appendix will be removed. QoS NSLP is a generic QoS Signaling Protocol that can signal for many QoS Models. A QoS Model is a particular QoS provisioning method or QoS architecture such a IntServ Controlled Load, Guaranteed Service, DiffServ or RMD. The definition of the QoS Model is independent from the definition of QoS-NSLP. Existing QoS Models do not specify how to use QoS NSLP to signal for them. Therefore, we need to define the QoS Signaling Models (QSMs), specific to each QoS Model, which describes the QoS Model specific signaling functions. In this draft we defined the RMD QoS Signaling Model to signal for RMD. Another QoS Signaling Model was defined for IntServ Controlled Load in [7]. Bader, et al. [Page 12] INTERNET-DRAFT RMD QoS signaling model A QSM should include the following information (for an illustration see this draft): - Role of QNEs in the QoS Model: E.g. location, frequency, statefulness... - QSpec Definition: QoS NSLP carries QSM-specific information in the QSpec object. The QSpec is opaque to QoS NSLP. It contains the QoS Signaling Model specific control information and QoS description parameters. QoS description parameters can have sub-objects e.g. corresponding to the TSpec, RSpec and AdSpec objects specified in RSVP. QSM should specify QSpec. - Message Format Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY messgages - State Management It describes how QSpec info is treated and interpreted in the Resource Management Function and QSM specific processing, e.g. admission control, scheduling, policy control, QoS parameter accumulation (e.g. delay)à - Operation and Sequence of Events Usage of QoS-NSLP messages to signal the QoS model. Intellectual Property Statement Ericsson will issue an IPR statement about RMD. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Bader, et al. [Page 13] INTERNET-DRAFT RMD QoS signaling model The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Bader, et al. [Page 14]