Internet Draft N. Ghani Expiration: January 2001 Sorrento Networks File: draft-ghani-odsi-cops-00.txt Z. Zhang Sorrento Networks L. Zhang Sorrento Networks J. Fu Sorrento Networks COPS Usage for ODSI July 5, 2000 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 ay 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 (2000). All Rights Reserved. Abstract ODSI is a framework of protocols designed to allow internetworking devices to dynamically request bandwidth from optical networks. Within this framework, a protocol is required for policy provisioning inside the optical domain. This documents defines the application of the IETF Common Open Policy Service (COPS) protocol for this purpose and details its interworking with the ODSI framework. 1. Introduction The IETF Common Open Policy Service (COPS) protocol is a well-defined policy provisioning protocol. Owing to its generic specification, COPS can also be applied within the optical networks space for authentication and resource control functions. This is a crucial requirement for optical networks and will allow operators to specifically engineer policies to meet their operational requirements. Along these lines, this document describes the application of the COPS protocol within the ODSI framework. A brief introduction to the COPS protocol is first presented, and subsequently, its interworking with the ODSI protocols framework is detailed. 2. Review of the COPS Protocol A very brief outline of the COPS protocol framework is first given. However, this summary is only intended to serve as a background reference, and interested readers are referred to the various protocol specification documents [Ref1, Ref2,Ref6] for full details. 2.1 Functional Overview COPS is a query/response protocol based upon a client/server model and has been designed for policy and admission control for a generic set of network resources. Although it is being developed by the IETF RAP (Resource Allocation Protocol) group, owing to its inherently generalized design, it can clearly be applied under a much broader context. The framework defines client entities, termed Policy Enforcement Points (PEPs), and server entities, termed Policy Decision Points (PDPs), which exchange policy information through various message types. At least one PDP entity has to be defined for an administrative domain. The messages include request, update, and delete messages from the PEP and decision and update messages from the PDP server (see Section 2.2 also). COPS has been designed to support multiple policy clients [Ref2], and examples include quality of service (QOS), security, customer-specific, etc. Therefore, to distinguish between different client types, a client type must be specified in each message. Each client type can have its own specific data and policy decision rules. Note that a single PEP or PDP can support policy provisioning for multiple client types. +-----------------+ | Network Node | Policy Server | +-----+ | COPS +-----+ | | PEP |<------+----------->| PDP | | +-----+ | +-----+ | ^ | | | +------+ | | +->| LPDP | | | +------+ | +-----------------+ Figure 1: A COPS illustration (from [Ref1]). The overall interaction between the respective COPS protocol entities is shown in Figure 1 (from [Ref1]). Specifically, the COPS protocol message set details the information exchange between the client PEP and remote PDP server. Additionally, an optional Local Policy Decision Point (LPDP) entity can also be associated with a network device to execute "local" policy decisions. However, all local decision information must be relayed to the PDP also (i.e., by the PEP in the form of an LPDP decision object), and the PDP entity remains as the binding decision point for all PEP requests. A PEP client communicates with its PDP server to implement various policy decision frameworks. As a network client, the PEP initiates this communication by opening a persistent (two-way) TCP connection to the PDP, and this connection is used for all communications between these two entities. TCP is chosen due to the important nature of the policy control information carried. This choice precludes the need for any additional mechanisms for reliable communication. COPS can function in two basic models, outsourcing and provisioning [Ref2] and defines various objects for its functioning, see [Ref1]. n the outsourcing model represents a client-driven approach, where the PDP server actively responds to incoming policy requests from PEP clients. This model works well for signaled protocols, e.g., as in RSVP-COPS [Ref6]. Client requests are carried via COPS-PR defined data objects, which communicate Client Specific Information objects [Ref7]. The format of this data is independent of the actual messaging protocol, and hence this decouples the information model from the actual signaling semantics. For example, RSVP-COPS requires all RSVP Path message data to be directly encapsulated into associated COPS message types (see [Ref6] for details). Examples of various RSVP PEP-PDP message exchange sequences are also detailed in [Ref6]. Meanwhile, the provisioning model represents a server-driven approach, where the PDP downloads (pre-provisions) policy information to client PEPs beforehand. Such policy information is based upon predicted configurations/demands and works well for non-signaled protocols/ scenarios. Specifically, after the PEP-PDP connection is setup, the PEP sends a configuration request message to the PDP, which in turn replies with a message containing all provisionable policies for the PEP device. Alternatively, the PDP can also asynchronously "push" policy state onto the PEP. Meanwhile, the actual COPS policy data is represented via a named "self-identifying" data structure, termed the Policy Information Base (PIB) [Ref2]. This structure specifies the type and purpose of the policy information arriving from the PDP, and hence must also be client specific. This information is installed by the PEP. Conceptually, PIB can be described using a tree structure, consisting of Policy Rule Classes (PRCs) and their associated Policy Rule Instances (PRIs), see [Ref2]. The overall PIB concept is very flexible, and the class/rule definitions can be further modified between PEP/PDP nodes to reflect new policy requirements, e.g., expiration quotas, time-of-day restrictions, and other SLA details (see [Ref2]). In the provisioning model, the PDP can re-issue updated policies to PEPs at any time, i.e., asynchronous updates. After any installation/ deletion of such configuration data from the PDP, PEP nodes must send appropriate report messages to the PDP for accounting and monitoring purposes. COPS relies upon a state-based model, where the request/decision state is shared between the PEP and PDP. Specifically, PEP requests are stored on the PDP until explicitly deleted (signaled) from the PEP. These stored requests can have an impact on how the PDP servers process future requests (i.e., based upon current request/decision states). PEP clients whose request states change must notify their PDP servers to the effect and delete non-applicable state information. However, PDP servers can also issue unsolicited messages (e.g., state updates) to PEP clients in order to force existing states. This may be necessary during policy upgrades or SLA changes. Depending upon the client type, multiple states can be installed for a single PEP/PDP relationship (as identified by the Handle object). Due to the important role of the COPS protocol, fault-tolerance features are also provided. These capabilities allow to "re-synchronize" state between the PEP and PDP in the event of a communications failure. The PEP-PDP connection is constantly verified using keep-alive messages, and upon failure detection, the PEP falls back to local decisions (via an LPDP). While disconnected from the PDP, the PEP tries to reconnect to the original PDP and/or to an alternative PDP [Ref1]. Upon connection re-establishment, the PEP must provide the PDP with new state and/or event information. Furthermore, the PDP can resynchronize all the PEP's internal state. See [Ref2] also for additional details on fault tolerance. Finally, security provisions for COPS are provided via an Integrity object, and all COPS implementations must support this object. Additionally, client (PEP) and server (PDP) entities can also use IP Security [Ref8] mechanisms to authenticate and secure the communications channel between the PEP and the PDP entities, as described in [Ref1]. 2.2 Message Set Summary A very brief summary of the COPS message set is presented to give a high-level view of some of the protocol's internals. Interested readers are referred to [Ref1],[Ref2] for more details: o Request (REQ) (PEP-to-PDP): PEPs send REQ messages to request policy provisioning data from the PDP. This message includes client-specific information to assist the PDP and also a unique Client Handle (to identify request states at the PEP and PDP entities). o Decision (DEC) (PDP-to-PEP): PDPs respond to client REQ messages via DEC messages. These messages contain multiple policy decisions that are to be installed on the PEP. DEC messages can be used to delete/ update existing rules (i.e., state) in the PEP. DEC messages use the lient Handle to identify the REQ being responded to. These messages contain command codes which instruct various operations on client- specific PIB entities. o Report State (RPT) (PEP-to-PDP): This message is sent from the PEP to the PDP to report accounting information. Also, a PEP must always report back to the PDP the outcome of action taken for an earlier DEC (install) message, i.e., indicating success or failure in applying the configuration action [Ref1]. o Delete Request State (DRQ) (PEP-to-PDP): This message is sent to the PDP in order to delete a request (or related information) pertaining to the specified Client Handle. PEPs can issue DRQ messages in response to status changes on their end (e.g., connection requests withdrawn by clients), and the PDP will take appropriate actions to remove state. It is important for PEPs to issue this command to ensure state consistency with the PDP. o Synchronize State Request (SSQ) (PDP-to-PEP): This message requests the PEP to re-send state information. The Client Handle field here is optional, and if specified, only the respective state needs be conveyed (via a PEP RPT message). If, however, no Client Handle is specified, the PEP must send all its state information to the PDP. o Client-Open (OPN) (PEP-to-PDP): This message is sent to the PDP server to specify various PEP-related information: client-types supported, last PDP connected to per client type, etc. Multiple such messages can be sent at anytime. PEP clients normally send an OPN message after connection establishment with a PDP server. o Client-Accept (CAT) (PDP-to-PEP): In response to the PEP OPN message, the PDP can respond "positively" with a CAT message. This reply contains various timer values which are used to generate keep- alive and/or accounting report messages. o Client-Close (CC) (PEP-to-PDP, PDP-to-PEP): This is a bi- directional message and indicates that a particular client type is no longer supported. This can be sent from the PDP in response to a PEP OPN message, in which case an alternative PDP server may also be specified. o Keep-Alive (KA) (PEP-to-PDP, PDP-to-PEP): These messages are transmitted by the PEP in order to maintain the PEP-PDP connection (i.e., independent of any particular client-type). Associated timer values for this message are specified by the PDP (e.g., via CAT response). The PDP must echo a keep-alive ACK message per incoming PEP keep-alive message. o Synchronize State Complete (SSC) (PEP-to-PDP): This message is sent by the PEP after receiving a PDP SSQ message, and indicates that (state) synchronization between the PEP and PDP is complete. This message may or may not include a Client Handle (as per the original PDP SSQ request message). 3. COPS Applied to the ODSI Framework Clearly, COPS provides a very generic policy control framework that is very extensible to the optical networking domain. With recent trends towards IP-based control for optical networks, the use of this framework will further provide for a more seamless interworking with P-controlled devices. Moreover, the built-in reliability and security features of this protocol ensure its applicability to robust services- provisioning scenarios. Hence, it is logical to interwork the COPS and ODSI frameworks together in order to provide a comprehensive policy provisioning setup for optical networks and extend optical policy provisioning closer to the network edge. In particular, the ODSI interface on edge optical devices must communicate with a COPS PEP entity in order to relay policy provisioning request/responses messages. Since the PEP deals with optical network policy administration, it must reside in an edge optical device. This overall framework is illustrated more clearly in Figure 2, where the PEP client communicates with the ODSI interface. +---------------------+ +-------------+ | Edge optical node | | User Device | | | Policy Server | +-------+ | | +-------+-----+ | +-----+ | | ODSI |<-+--------+-->| ODSI | PEP |<--+------>| PDP | | | Int. | | ODSI | | Int. | | | COPS +-----+ | +-------+ | mesgs | +--+----+--^--+ | mesgs | | | | | +-------------+ | | | | +---v--+ | | | LPDP | | | +------+ | +---------------------+ Figure 2: COPS applied to the ODSI framework Initially, the ODSI user device-to-optical interface is setup by a series of procedures (service discovery, address registration, signaling, see [Ref3],[Ref4],[Ref5]). After this procedure is complete, the COPS startup procedures can be initiated. In the above interworking, the ODSI interface residing in the edge optical device passes messaging between the (optical domain) PEP and the (electronic domain) user device, e.g., such as an IP router or SONET digital cross- connect. In particular, this entity translates ODSI actions into appropriate PEP client actions. Subsequently, the optical PEP entity sends back appropriate reply messages to the ODSI interface. Here, the outsourcing policy management model is applied for COPS-ODSI interworking (akin to RSVP-COPS interworking [Ref6]), and ODSI actions are transmitted to the PDP via the local PEP entities. In this case, the PDP (LPDP) returns policy responses to the PEP, which are in turn translated into appropriate ODSI interface actions and/or messages. Therefore, when PEPs open communications with PDP servers, their initial Client-Open (OPN) messages have the client-type set to indicate a signaled client. In particular, a new signaled client type ODSI is defined. If the PDP supports this client-type, it responds with a Client-Accept (CAT) message or otherwise with a Client-Close (CC) message. Alternatively, the PDP can also redirect the PEP to other PDPs in the network domain (via a Redirect address in the CC message). After receiving a CAT message, the PEP can issue the first (ODSI-driven) request message to the PDP server. Meanwhile, the information transfer model assumes that all objects received in the ODSI messages are encapsulated in a Client Specific Information Object (Signaled ClientSI) and sent from the PEP to the PDP. Specifically, ODSI trail request messages will contain topological information (source, destination IP addresses and port numbers), bandwidth requirements, protection levels, preemption priorities, and setup priority. It assumed that the (ODSI policy server) PDP is fully ODSI-aware and can handle these message contents and generate appropriate policy control decisions. ODSI clients are divided into user groups, and bandwidth creation is strictly restricted to (client) user devices belonging to the same OSDI user group [Ref5]. In particular, "admission control" is applied based upon the user group and requester and endpoints (as per functional specification [Ref1]). Hence, when fielding bandwidth requests, ODSI components must first resolve the IP addresses of the endpoints and resolve the associated user group value. This information, along with the details of the ODSI bandwidth request is then forwarded to the COPS policy server (i.e., optical network PDP), which will perform the necessary policy provisioning and accounting procedures on the request. Also note that the ODSI specification states that (electronic client) endpoints may be partially specified [Ref3]. By this it is meant that the complete endpoint information may not be given (i.e., port numbers). However, the endpoint IP addresses are always specified, and user group identification should be possible with this information alone. As per the ODSI signaling specification [Ref4], the request is propagated from (trail) requester to (trail) head to (trail) tail, and then to an optical network controller (ONC) entity. The ONC validates the request and subsequently allocates the resources for the circuit. Now clearly, one of these ODSI entities must initiate policy provisioning via COPS. To functionally decouple the ODSI and COPS entities, it is felt here that such policy requests are best done by the trail head entity, i.e., PEP entity in Figure 2 only provisions policy for electronic client nodes connected to its optical device. Since this point in the network will source the request, it is logical for the PEP entity associated with the trail head to request policy clearance from the network PDP server. If the policy requirements are valid, the request can be further propagated to the trail tail. Otherwise, the request must be rejected (by sending an ODSI trail notification message to the trail requester). In the case the trail head does not have ODSI-COPS interworking (i.e., no PEP entity), the request must again be rejected. In the following section, the message format will be specified in more details. 4. Message Contents The COPS protocol provides the capability for different COPS clients to define their own "named", i.e. client-specific, information for various messages. This section describes the messages exchanged between a COPS server (PDP) and COPS ODSI clients (PEP) that carry client- specific data objects. Since ODSI is a signaled client, a new signaled client-type value is defined (TBD) for the common header field. 4.1. Request (REQ) PEP -> PDP The REQ message is sent by COPS-ODSI clients to issue a 'Trail Request' to the PDP. The Trail Request REQ is used to request a new trail, to modify or non-destructively modify a previously established trail, to query and to release a trail. The Client Handle associated with the EQ message originated by a client must be unique for that client. he Client Specific info object is used to specify the requested resources and the request identifier. Each REQ message contains a single request. The PDP responds to the resource allocation request with a DEC message containing the answer to the query. The REQ message has the following format: <Request> ::= <Common Header> <Client Handle> <Context > [<ClientSI: all objects in ODSI Trail Create Request >] [<LPDPDecision(s)>] [<Integrity>] The only ODSI message type supported by COPS is Trail Create Request (actions: create, destroy, query, modify, indicated by the _action indicator flag_). The other two ODSI messages, Trail Create Acknowledge and Trail Notification, are not supported by COPS. All objects that were received in the ODSI Trail Create Request are encapsulated inside the Client Specific Information (ClientSI) Object sent from PEP to the remote PDP. <ClientSI: Request ID all objects in Trail Create Request> If the request is a Modify request, the previous value for starting time should be appended at the end of ClientSI object (for accounting purpose): <ClientSI: trail attribute data >:: Request ID Trail Create Request ODSI message <starting time> (new value) <starting time> (old value) The LPDPDecision can be specified if applicable. 4.2. Decision (DEC) PDP -> PEP The DEC message is sent from the PDP to a COPS-ODSI client in response to the REQ message received from the PEP. Unsolicited DEC messages cannot be sent for this client type (therefore the solicited decision flag is always set). The Client Handle must be the same Handle that was received in the REQ message. PDP performs admission control for Trail Create Request based on the User Group Id, and some other criteria. The Decision object will contain in the Client Specific info the Request ID, which is needed by the PEP to correlate the reply with the query. Each DEC message contains a single decision. The DEC message for the COPS-ODSI client type has the following format: <Decision Message> ::= <Common Header> <Client Handle> <Decision> | <Error> [<Integrity>] The decision object in turn has the following format: <Decision> ::= <Context> <Decision: Flags> <Decision: Client SI data> The context object will be the same as contained in the REQ message. The Decision: Flags object will contain the answer in the Command-code field according to the COPS specifications. In particular the Command- code will be "Install" to mean a positive answer and "Remove" to mean a negative answer. The following text clarifies how Install and Remove Decisions map into the different request types. REQ (_action_indicator flag_ = Add) DEC (Dec Flag = Install) -> The requested resources are successfully allocated DEC (Dec Flag = Remove) -> The requested resources are not allocated REQ (_action_indicator flag_ = Release) DEC (Dec flag = Install) -> The resources are released DEC (Dec Flag = Remove) -> The resources are still allocated. REQ (_action_indicator flag_ = Modify) DEC (Dec flag = Install) -> The modification is accepted. The newly requested resources are allocated, while the previous ones have been released DEC (Dec Flag = Remove) -> The modification is not accepted. Previous allocation is still active. REQ (_action_indicator flag_ = Query) DEC (Dec flag = Install) -> The request for query is accepted. DEC (Dec Flag = Remove) -> The request for query is not accepted. The Error object is used to communicate COPS protocol error to the PEP, according to the definition in [Ref1]. No client specific error sub- codes are used by COPS-ODSI. The Decision ClientSI data object carries the information needed to correlate the decision with the answer and some optional information to explain negative Decisions. It has the following format: <Decision: Client SI data> ::= <Request ID> <Reject Reason> Possible reasons are: Resource unavailable Unsupported resource type Unacceptable source address Unacceptable destination address No report is sent by the PEP to confirm the reception of a Decision message. Only in case of specific errors, the PEP will send back a Report State message to the PDP. 4.3. Report State (RPT) PEP -> PDP For COPS-ODSI client type, the Report State message is sent by the PEP to the PDP in case of problems with a received Decision message. More specifically it is used to communicate that the Decision contains a Request identifier which cannot be correlated to a previous request. This event is the manifestation of abnormal behavior. On reception of a Report State message the PDP could start a Synchronization procedure. The RPT message for the COPS-ODSI client type has the following format: <Report State Message> ::= <Common Header> <Client Handle> <Report Type> <ClientSI: Request ID> [<Integrity>] 4.4. Synchronize State Request (SSQ) PDP -> PEP The Synchronize State Request message is sent by the PDP to the PEP to "reset" the state information. It requests the PEP to send the set of resource allocation REQ messages needed to rebuild the state. The SSQ can apply to the whole set of PEP active reservations PEP, or to a specific resource type and source-destination couple, depending on the nformation contained in the Client SI object. < Synchronize State> ::= <Common Header> <Client Handle> <ClientSI: SSQ scope>] [<Integrity>] 4.5. Synchronize State Complete (SSC) PEP -> PDP The Synchronize State Complete message is sent by the PEP to the PDP to inform that all the REQ messages needed to rebuild the state have been sent. The Client SI object is the same received in the SSQ message and specifies the scope of the synchronization procedure which has been completed. < Synchronize State Complete> ::= <Common Header> <Client Handle> <ClientSI: SSQ scope>] [<Integrity>] 5. Illustrative Examples In this section, some illustrative examples for the COPS-ODSI client interworking are presented. In the first example, the trail request is successful, and in the second example the request is rejected. A PEP requests an OC48 trail between Head (192.234.124.1) and Tail (192.234.4.1). PEP -- > PDP REQ: = <Handle C> <Context: Trail Request, Add> <ClientSI: Request ID: 25 ** start of ODSI Trail Create Request message ** User Group: X Source Address: 192.234.124.1 Destination address: 192.234.4.1 Bandwidth type: OC48 ** end of ODSI Create message *** Starting time: 0.0.0 > The PDP accepts the request. PDP--- > PEP DEC: = <Handle C> <Context: Trail Request, Add> <Decision: Command = Install> <Decision: Client SI Request ID 25 > In the following example, the trail request of an OC192 between Head (192.234.1244.1) and Tail (192.234.4.1) is rejected. The same handle and user group are used but the Request ID is different. PEP -- > PDP REQ: = <Handle C> <Context: Trail Request, Add> <ClientSI: Request ID: 28 ** start of ODSI Trail Create Request message ** User Group: X Source Address: 192.234.124.1 Destination address: 192.234.4.1 Bandwidth type: OC192 ** end of ODSI Create message *** Starting time: 0.0.0 > PDP--- > PEP DEC: = <Handle C> <Context: Request Request, Add> <Decision: Command = Remove> <Decision: Client SI Request ID 28 Reason code: resource unavailable > 5. References [Ref1] Durham, D., Boyle, J., R. Cohen, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, January 2000. [Ref2] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie, K., Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage for Policy Provisioning", IETF Draft draft-ietf-rap-pr-02.txt, March 10, 2000. [Ref3] ODSI Coalition, G. Bernstein, R. Coltun, J. Moy and A. Sodder, editors, "Optical Domain Service Interconnect (ODSI) Functional Specification", March 2000. [Ref4] Bernstein, G., Coulton, R., Moy, J., Sodder, A., "Optical Domain Service Interconnect (ODSI) Signaling Specification", April 2000. [Ref5] Bernstein, G., Coulton, R., Moy, J., Sodder, A., Arvind, K., "ODSI Service Discovery and Address Registration," April 2000. [Ref6] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., Sastry, A., "COPS Usage for RSVP," IETF RFC 2749, January 2000. [Ref7] Durham, D., Khosravi, H., Weiss, W., Avri, D., "COPS Usage for AAA," IETF Draft draft-durham-aaa-cops-ext-00.txt, May 2000. [Ref8] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, August 1995. 6. Authors' Information Nasir Ghani Sorrento Networks Inc., 9990 Mesa Rim Road San Diego, CA 92121 Phone: (858) 646-7192 Email: nghani@sorrentonet.com Zhensheng Zhang Sorrento Networks Inc., 9990 Mesa Rim Road San Diego, CA 92121 Phone: (858) 646-7195 Email: zzhang@sorrentonet.com Leah Zhang Sorrento Networks Inc., 9990 Mesa Rim Road San Diego, CA 92121 Phone: (858) 450-4977 Email: leahz@sorrentonet.com James Fu Sorrento Networks Inc., 9990 Mesa Rim Road San Diego, CA 92121 Phone: (858) 450-4924 Email: jfu@sorrentonet.com 7. Full Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.