Internet Draft Robert Hancock Eleanor Hepworth Andrew McDonald Siemens/Roke Manor Research Document: draft-hancock-nsis-sender- receiver-00.txt Expires: April 2003 October 2002 Sender and Receiver Orientation Issues in NSIS draft-hancock-nsis-sender-receiver-00.txt 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 The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2] and a framework in [3]. It is clear from existing work that there are many interrelated issues with NSIS signaling, concerning the respective roles of the two ends of the communication path. These issues include route finding, authorisation, state management requirements, localization of negotiation, and so on. The wide variety of problems involved hinders progress in deciding what approach NSIS should adopt. This Internet Draft attempts to provide a summary of these issues and suggests a way of structuring further analysis. It is not expected that this document should have a long term existence. Hancock et al. Expires - April 2003 [Page 1] NSIS: Sender/Receiver Issues October 2002 Conventions used in this document 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 [4]. Table of Contents 1. Introduction, Terminology, and Scope...........................2 1.1 Data and Signaling Flows ...................................2 1.2 Status of Existing Protocols ...............................4 1.3 Protocol Layering Assumptions ..............................4 2. Constraints on Sender/Receiver Orientation.....................5 2.1 Signaling Message Routing ..................................5 2.2 User Application Triggering ................................5 2.3 Renegotiation ..............................................6 2.4 'Service' Authorization ....................................6 2.5 Localized Signaling Support ................................8 2.6 Protocol - Protocol Interactions ...........................9 2.7 Multicast Support ..........................................9 2.8 Something Unpleasant about NAT .............................9 2.9 Summary ...................................................10 3. Possible Approaches...........................................10 3.1 Fix on One Paradigm .......................................10 3.2 Allow Both Paradigms ......................................11 3.3 Choose Separately for Each Protocol Component .............11 3.4 Implications of a Layered Choice ..........................12 4. Additional Considerations.....................................12 4.1 Bidirectional Reservations ................................12 4.2 Path-Decoupled Signaling ..................................13 5. Conclusions...................................................14 Acknowledgments..................................................15 Author's Addresses...............................................15 Full Copyright Statement.........................................15 1. Introduction, Terminology, and Scope Unless otherwise stated, this document follows the terminology given in the current NSIS framework [3]. 1.1 Data and Signaling Flows For the bulk of this document, we are concerned with path-coupled signaling for a single unidirectional flow, as shown in Figure 1 (additional considerations are given in section 4). The node that is sending the user data packets is called the 'sender' and the node Hancock et al. Expires - April 2003 [Page 2] NSIS: Sender/Receiver Issues October 2002 sinking them the 'receiver'; these packets pass through one or more routers. +--------+ +-+ +-+ +-+ +--------+ | Sender |------->|R|------->|R|------->|R|------->|Receiver| +--------+ +-+ +-+ +-+ +--------+ ----------> = Flow of user data packets Figure 1: Sender and Receiver In the case of path-coupled NSIS signaling, there are signaling nodes (NSIS entities) along the data path. The NSIS initiator (NI) notionally controls the signaling (e.g. at application request), whereas the NSIS responder (NR) terminates the signaling at the far end; there may be one of more NSIS forwarders (NF) between the two. The NI and NR do not have to be colocated with sender and receiver (e.g. they could be at first/last hop access routers); nor do they have to be the same 'way round' as the sender and receiver. This leads to two different cases for analysis. Figure 2 shows the 'sender initiated' case, and Figure 3 shows the 'receiver initiated' case. +--------+ +--+ +--+ +--+ +--------+ | Sender |------->|NI|------>|NF|------>|NR|------>|Receiver| +--------+ +--+ +--+ +--+ +--------+ ========> ========> ========> = Flow of NSIS 'control' Figure 2: Sender Initiation +--------+ +--+ +--+ +--+ +--------+ | Sender |------->|NR|------>|NF|------>|NI|------>|Receiver| +--------+ +--+ +--+ +--+ +--------+ <======== <======== ========> = Flow of NSIS 'control' Figure 3: Receiver Initiation One of the basic open issues in NSIS is whether one or both of these models should be supported, and in either case, what is the real difference in functionality between the NI and NR; to put it another Hancock et al. Expires - April 2003 [Page 3] NSIS: Sender/Receiver Issues October 2002 way, how 'directional' is the relationship between NSIS entities (which up to now has not really been defined). It is the purpose of this document to gather together some of the information about this subject and propose a way forward. 1.2 Status of Existing Protocols The principle existing path-coupled signaling protocol is RSVP [5]. RSVP is commonly described as 'receiver initiated', although there are some subtleties in this categorization. From the point of view of the act of resource reservation, RSVP is clearly receiver initiated, in that the receiver is responsible for generating the RESV message which actually defines the QoS that the receiver wants for incoming traffic. This RESV message can also be accompanied with security-related policy information to support the request (see [6]). The primary motivation behind adopting receiver initiation for resource reservation appears to have been multicast support, as described in [7]. On the other hand, key elements of RSVP operation (RESV routing and route change detection) depend on the PATH message which is generated by the sender, and can be seen as triggering the RESV message (at least the first one). This sender-generated message also contains QoS-related information (and can even contain policy elements). We can therefore see RSVP as containing several functions, some sender oriented and some receiver oriented. It might be that this distinction should be carried over into a successor protocol. 1.3 Protocol Layering Assumptions The working assumption in the NSIS group is the signaling protocol should be 'layered' in two parts (see section 4 of [3] for more details), and this is consistent with several protocol proposals, such as CSTP/ALSP [8] and others too provocative to mention here. In this document, we refer to these layers as follows: *) The 'NSIS Base Protocol' (NBP), handling message routing aspects specific to path-coupled signaling; it may include transport-layer- like functionality (reliability, congestion control and so on) or be layered on an existing transport protocol. *) 'A Signaling Application Protocol' (ASAP), a 'placeholder' for one of many possible protocols which handle particular signaling applications (QoS, middlebox control, and so on). Hancock et al. Expires - April 2003 [Page 4] NSIS: Sender/Receiver Issues October 2002 2. Constraints on Sender/Receiver Orientation Depending on the particular NSIS function (or specific signaling application function) under consideration, it may be much easier to implement it in a sender or receiver 'oriented' way. This section summarizes these various constraints or influences. 2.1 Signaling Message Routing Regardless of the particular signaling application in question, path- coupled signaling requires the capability of message routing along the path from sender to receiver. It appears that there are only two methods for the signaling protocol to acquire awareness of the route: *) Using a PATH mechanism similar to RSVP. *) Using local topology information (e.g. from a routing protocol, or local configuration). Signaling message routing, which is a function of the NBP layer, should therefore be sender oriented, possibly with the ability to use additional information sources if available. A related question is whether signaling messages need to be routed with or against the data flow (or both). (So far as we can tell, the NBP layer only sends and receives messages over a single NSIS hop, so the question only applies to the ASAP layer. It applies both to 'real' signaling application messages and probably also to application-specific error notifications.) If messages need to be routed against the data flow, this has implications for the need to store reverse-path message routing state at intermediate nodes. The conclusion therefore seems to be that the NBP layer should be able to operate in a sender-oriented mode, but what state it needs to store depends on ASAP layer requirements. 2.2 User Application Triggering Ultimately, the NSIS signaling is supporting the requirements of some user application (e.g. a VoIP or other media capability). It is likely that sometimes, only one 'party' will have a clear view on what to request, e.g. what is the appropriate QoS, or even what are the flow identification characteristics (port numbers or flow labels may be allocated only at the sender). Even if both ends know, still one end probably knows first and communicates the information via upper layer exchanges; therefore, fixing sender or receiver orientation for NSIS signaling may impose additional roundtrip delays compared to an 'optimised' solution. Hancock et al. Expires - April 2003 [Page 5] NSIS: Sender/Receiver Issues October 2002 The constraints here are probably both *) Signaling application specific, and *) User application specific. 2.3 Renegotiation There has been some discussion (requirement 5.6.3 of [2] and section 3.3.2 of [3]) of the need for flexibility in which entities can renegotiate aspects of a reservation - for example, whether the sender or receiver should be able to do this, or the initiator or responder, or whether it should be possible from within the network. This is probably a question which depends on the ASAP layer. If additional flexibility has to be supported for renegotiation compared to initial reservation setup, then this will be an additional source of complexity. Note that some of the motivation for this flexibility is (presumably) to allow localized renegotiation, which is also discussed in section 2.5. 2.4 'Service' Authorization When any 'resource' is being requested from the network, in some cases the use of this resource must be authorised (or somehow verified to be compatible with a network's internal policy requirements). It is a hard question to work out how authorisation approaches might impact on the sender/receiver orientation aspects. For example, it is possible that current inter-provider peering agreements would favour a 'sender-initiated' authorisation approach, since typically the traffic originator 'pays' for traffic. On the other hand, in mobile environments, the mobile user may be prepared to authorise a resource request for both directions; a firewall application may only accept resource requests from one side. Therefore, the service authorisation constraints on sender/receiver orientation are both *) Signaling application dependent, and *) Network policy dependent (although it may be the case that for any given signaling application, there is a single 'natural' authorisation direction). Indeed, even for a single path, the network policy may change at provider boundaries. One reason why sender/receiver authorisation has an impact on signaling flows is the state management aspects while a request is being authorised end to end. For example, Figure 4 shows a 'initiator authorised' signaling flow: messages flowing in the direction NI-->NF-->NR can carry their own authorisation data (they could even Hancock et al. Expires - April 2003 [Page 6] NSIS: Sender/Receiver Issues October 2002 carry it idempotently/statelessly), which could allow very simple authorisation processing at intermediate nodes. +--+ | |NI| | +--+ 1: Resource request (with | \ authorisation data) for | \ first segment of data path | \ | _| | +---+ 2: Authorisation verified by NF1 | T |NF1| and request admitted; resource | I +---+ request propagated to next segment | M \ | E \ 3: Resource request for | \ second segment of data path | _| | +---+ | |NF2| V +---+ V . V . V Figure 4: Message Flow for Initiator Authorisation However, the 'responder authorised' situation is more complex, since the actual authorisation data has to come from the remote end of the signaling exchange, and intermediate nodes may have to retain state waiting for this to arrive, as shown in Figure 5. The conclusion from this part of the discussion is that: *) Either the initiator or the responder might be responsible for authorisation aspects (depending on the discussion above), but *) If the responder is responsible, the NBP will have to handle messages in both directions, and intermediate nodes will have to handle more local state storage. Hancock et al. Expires - April 2003 [Page 7] NSIS: Sender/Receiver Issues October 2002 +--+ |NI| | +--+ | \ 1: Resource request for | \ first segment of path | \ | _| | +--+ 2: Resource request | {|NF| propagated | {+--+ to next segment | { \ | { \ 3: Resource request for | T During steps { \ second segment of path | I 2 to 5: { _| | M NF awaiting { +--+ | E authorisation { |NR| 4: NR generates | information { +--+ authorisation info | from NR { / | { / 5: Authorisation | { / information from NR | { |_ for second segment | {+--+ V {|NF| V +--+ V . V . Figure 5: Message Flows for Responder Authorisation 2.5 Localized Signaling Support Technical approaches for localization of signaling have already been discussed in the context of RSVP, for example in [9] and [10]. There are several reasons why it may be desirable to localize the scope of some aspect of the signaling, such as: *) Only one endpoint may be generally NSIS aware (e.g. because the other endpoint has no motivation to implement it, or because it is a legacy device). *) Only one endpoint may be aware of the specific ASAP which is relevant. *) One endpoint may be mobile and wish to manage aspects of its reservations locally to improve handover performance. Regardless of the motivation, the end result is that in some scenarios, an endpoint will probably wish to carry out both sender and receiver oriented signaling over some local region of the network, i.e. for incoming and outgoing packets for a bi-directional session. Ideally this would be done both: Hancock et al. Expires - April 2003 [Page 8] NSIS: Sender/Receiver Issues October 2002 *) for the NBP layer (although we have said in 2.1 that this is hard), and *) for the ASAP layer. In practice, the mechanism for localizing signaling will be some kind of proxy, and the difficulty in the NBP layer is precisely the difficulty in locating the proxy using purely local signaling. Given the proxy location, however, the ASAP layer signaling between it and the end point then suffers from all the same constraints related to sender/receiver orientation as in the end to end case. 2.6 Protocol - Protocol Interactions As well as operating locally (in isolation), NSIS signaling will have to interact with other protocols, such as RSVP in other parts of the network. Also, several NSIS deployment scenarios consider NSIS interacting with itself in a 'layered' style, or end-to-end NSIS using edge-to-edge signaling for intradomain provisioning (see for examples sections 3.2 and 7 of [3]). In these circumstances, NSIS is at least partly at the mercy of these other protocols or other instances of itself, to be initiated and to respond in a compatible way at the protocol interworking boundary. In particular, to interwork with RSVP, NSIS signaling may have to be able to operate in compatible way (e.g. receiver oriented for reservation). 2.7 Multicast Support Multicast support is the primary justification for the receiver orientation of the reservation signaling in RSVP. The reason is that this naturally allows for progressive state merging from large numbers of receivers back towards the senders, thereby allowing better scalability. For the most general multicast case, this conclusion seems unchallenged (although restricted multicast scenarios, such SSM [11] or multicast with homogeneous receivers, other options may be possible). Multicast support is not an initial requirement for NSIS protocol work. However, in the future, it might be desirable to extend parts of NSIS to support multicast signaling applications, in which case particular sorts of receiver orientation should not be permanently excluded. 2.8 Something Unpleasant about NAT The existence of NATs poses some special problems for signaling protocols, since they change the header information in packets Hancock et al. Expires - April 2003 [Page 9] NSIS: Sender/Receiver Issues October 2002 downstream from the sender in a way which may not be predictable before the data flow along the path is actually active (e.g. if dynamic address sharing is taking place). The consequence of this is that, even if we would naturally imagine a certain signaling operation being controlled from the receiver, this may not be possible because the receiver does not know how to refer to the flow in the first place. Therefore, the signaling has to at least involve the sender as well, probably in cooperation with the receiver (and NAT) as well. 2.9 Summary The overall conclusion of this section is that there are all sorts of reasons why: *) Sender orientiation may be required for some functions or in some scenarios; *) Receiver orientation may be required for other functions or other scenarios; *) Sender and receiver orientiation have different costs and complexities (e.g. in state management or latency) associated with them. The choice between sender and receiver orientation therefore appears as a classic rock and hard place dilemma, especially given the natural desire to build a solution that is not overwhelmed by complexity or option negotiation. 3. Possible Approaches This section presents three possible approaches to resolving this conundrum. 3.1 Fix on One Paradigm Initially, the most attractive possibility would be to fix on a single paradigm and impose it throughout the NSIS work. However, it seems impossible to imagine that a single paradigm will support all the requirements and scenarios under discussion; even the baseline RSVP approach, summarized in 1.2, covers only some of the possibilities, and in some scenarios simpler sender-only solutions are possible. A wider set of options might also make incremental deployment (which could be a critical issue) more achievable. Hancock et al. Expires - April 2003 [Page 10] NSIS: Sender/Receiver Issues October 2002 3.2 Allow Both Paradigms The opposite approach is to allow everything - all aspects of NSIS - to be both sender and receiver oriented. The basic danger here is of overwhelming the NSIS protocols with excessive complexity, since they may well have to operate differently depending on which direction they are working in. It would also make it more difficult to implement a minimal subset of NSIS for particularly constrained environments. Even if the NSIS protocols could be specified and implemented, the variety of options would pose some operational problems. It might be that both sender and receiver would attempt to initiate the signaling protocol and cause a protocol collision (or indeed that neither of them would). The necessary remedy for this would be to introduce yet another component of the NSIS protocol, to negotiate which end should take the initiative. 3.3 Choose Separately for Each Protocol Component A third way is to select between sender and receiver orientation independently for each component; provided the inter-component interactions can be controlled, this should then allow better fitting of protocol behavior to the constraints identified above. Specifically, we could imagine the following: The NBP layer would be (universally) sender oriented, the same way as the RSVP PATH message (possibly also allowing for other peer discovery mechanisms and proxy usage). The ASAP layer would be either sender or receiver oriented, depending on the signaling application in question. There might even be different variants for different deployment scenarios (e.g. a sender- oriented intra-domain QoS signaling application, which worked with a receiver-oriented inter-domain counterpart at domain boundaries). The operation of the NBP and ASAP layers would be interdependent to some extent. The dependencies would include: *) A receiver-oriented ASAP would suffer from (at least) a single end-to-end delay, waiting for the NBP layer to complete establishing the signaling path. However, this delay is probably an unavoidable consequence of whatever constraints meant the ASAP was receiver- oriented in the first place. *) The NBP might unnecessarily store reverse-path state for a purely sender-oriented ASAP (in other words, one which required no receiver- to-sender messages). This could be fine tuned by allowing the ASAP to invoke the NBP in a mode which didn't store such state. Hancock et al. Expires - April 2003 [Page 11] NSIS: Sender/Receiver Issues October 2002 3.4 Implications of a Layered Choice Splitting the responsibility in this way and leaving the selection to the ASAP layer represents quite a significant shift in thinking compared to current protocols. There are therefore some dangers. The first danger is of excessive flexibility. On the other hand, the flexibility is a consequence of the NSIS requirements and constraints. This approach does allow simpler solutions in particular environments (e.g. for specific ASAP layers). The split decision probably has implications for the way state is managed between the layers, especially where different layers are in different protocol states in the interior of the network. This clearly needs further analysis. If the choice between sender and receiver initiation is really a matter for the ASAP layer, the implication is that the messages visible in the NBP should be somewhat neutral in content. The existing NSIS framework (section 4.3.2 of [3]) may be too specific in this regard. Also, the basic NI/NF/NR concepts may have to be split depending on the NBP/ASAP layer. 4. Additional Considerations The adoption of a split approach for sender/receiver orientation could have some implications for other aspects of NSIS-related work beyond the basic unicast path-coupled case. These are summarized here. 4.1 Bidirectional Reservations NSIS work (especially requirements work) has discussed the case of 'bidirectional' reservations, in other words, signaling for both directions of a point-to-point data flow. The baseline approach for this feature (see section 3.2.7 of [3]) is to simply combine a pair of unidirectional reservations, which is then covered by the previous discussion. However, a 'true' bi-directional reservation (integrating the signaling for each direction) would also be interesting in some applications. Topologically, this would only be possible over a path segment that was symmetrically routed. Following the split layer approach of section 3.3, it seems that asking for bi-directional protocol within the NBP layer is not meaningful, since in general, even if the route is symmetric, NBP Hancock et al. Expires - April 2003 [Page 12] NSIS: Sender/Receiver Issues October 2002 layer procedures have to operate asymmetrically while finding this out. However, it could be possible for the NBP layer to detect this symmetry (i.e. correlate the routes for incoming and outgoing flows) and provide this as an enhanced service interface to the ASAP layer. Whether the ASAP layer can or must use this capability to set up a bi-directional reservation using that interface is probably very much dependent on the signaling application and possibly scenario in question. It seems likely that the logical behavior (to do with state management, message sequences and so on) is the same as just a sender and receiver initiated reservation; however, the sending and reception of the messages in pairs might enable more efficient local processing. 4.2 Path-Decoupled Signaling Although NSIS does not currently have path-decoupled signaling in its scope, it is worth pointing out here some issues that may be special related to sender/receiver aspects in the path-decoupled case. The main issue with path-decoupled signaling is that once the signaling endpoints are not on the data path, it is no longer an unambiguous topological decision to categorize one of them as being related to the sender and the other to the receiver (see Figure 6). +--------+ +-+ | Sender |------->|R| +--------+ +-+\ \ \ +--+ \ +--+ |NI|============>|NR| +--+ \ +--+ \ \ \+-+ +--------+ |R|------->|Receiver| +-+ +--------+ ----------> = Flow of user data packets ========> = Flow of NSIS 'control' Figure 6: Path-Decoupled Signaling Topology If there is to be an attempt to re-use path-coupled NSIS signaling in this type of environment, and the signaling depends significantly on Hancock et al. Expires - April 2003 [Page 13] NSIS: Sender/Receiver Issues October 2002 sender and receiver orientation, it will be necessary to work out how to match these concepts in the path-decoupled case. One approach to this would be to place the responsibility for 'path- orientation' in the NBP layer or its equivalent (which has to be modified anyway for the path-decoupled case to support off-path nodes). This layer will also have to have some more explicit (application layer?) interaction with the data sender and receiver, just to trigger the signaling process in the first place. However, once this is done, the ASAP layer (at least in terms of message exchanges) might operate in almost exactly the same way as in the path-coupled case. 5. Conclusions This document has no conclusions. However, it proposes a method for reasoning (possibly constructively) about the sender/receiver orientation possibilities. Implications for the requirements and framework, and consequences for path-decoupled signaling, have also been identified. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Brunner, M., "Requirements for QoS Signaling Protocols", draft- ietf-nsis-req-04.txt (work in progress), August 2002 3 Freytsis, I., R. E. Hancock, G. Karagiannis, J. Loughney, S. van den Bosch, "Next Steps in Signaling: Framework", draft-ietf-nsis- fw-00.txt (work in progress), October 2002 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 6 Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000 7 Braden, R. et al., "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994 Hancock et al. Expires - April 2003 [Page 14] NSIS: Sender/Receiver Issues October 2002 8 Braden, R., "A Two-Level Architecture for Internet Signaling", draft-braden-2level-signal-arch-00.txt (work in progress), November 2001 (expired) 9 Gai, S. et al., "RSVP Proxy", draft-ietf-rsvp-proxy-03.txt (work in progress), March 2002 10 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt (work in progress), May 2002 11 Bhattacharyya, S. et al., "An Overview of Source-Specific Multicast (SSM)", draft-ietf-ssm-overview-03.txt (work in progress), March 2002 Acknowledgments The authors would like to thank all their colleagues and fellow participants in the NSIS working group for exposing the complexities and subtleties in this subject area. Author's Addresses {Robert Hancock, Eleanor Hepworth, Andrew McDonald} Roke Manor Research Old Salisbury Lane Romsey Hampshire SO51 0ZN United Kingdom email: {robert.hancock|eleanor.hepworth|andrew.mcdonald}@roke.co.uk Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for Hancock et al. Expires - April 2003 [Page 15] NSIS: Sender/Receiver Issues October 2002 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. Hancock et al. Expires - April 2003 [Page 16]