IEPREP Working Group Pat McGregor Internet Draft Richard Kaczmarek Expires December 23, 2003 Nyquetek Inc Category: Best Current Practice Dennis Berg File: draft-mcgregor-ieprep-bridging-bcp-00.txt Janet Gunn CSC June 2003 MPLS IP Bridging Configuration Guidance for IEPREP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 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. This Internet-Draft will expire on December 23, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract An Internet Emergency Preparedness (IEPREP) telephony service IP Bridging topology using Multi-Protocol Label Switching (MPLS) should provide Emergency Telecommunications Service (ETS) using a) Session Initiation Protocol (SIP) Priority header value of "emergency", b) Session Description Protocol (SDP) attribute experimental parameters to designate the call (session) as either a National Emergency call, International Emergency call, or both, c) MEGACO context descriptors of McGregor et al Expires December 23, 2003 [Page 1] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 priorities 1-6 and emergency indication, and d) MPLS E-LSPs with a dedicated codepoint specifying application of ETS Per-Hop Behavior (PHB). IP Differentiated Services marking should use specified code points allocated from the Experimental and Local Use pool (pool 2) to designate the traffic as either National Emergency or International Emergency for corresponding PHB use. Signaling between the Signaling Gateway (SG) and Media Gateway Controller (MGC) should apply the MTP3 SS7 protocol over the M2UA adaptation protocol for use of the Stream Control Transmission Protocol (SCTP). Support is suggested for work in progress on defining a SIP Resource Priority header and defining a SIP telephone url extension for calling party category designation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terms and Definitions . . . . . . . . . . . . . . . . . . 4 2. IP Bridging Topology . . . . . . . . . . . . . . . . . . . . 4 3. MLPS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. MEGACO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 8 7. Differentiated Services Code Points . . . . . . . . . . . . . 9 8. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13 McGregor et al Expires December 23, 2003 [Page 2] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 1. Introduction The Internet Emergency Preparedness (IEPREP) Working Group charter notes that effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, and that the Internet community needs to consider how it can best support emergency management and recovery operations. This document presents recommendations for Emergency Telecommunications Service (ETS) telephony application design with existing protocols in an IP Bridging topology. User requirements for IP-based networks to enable and support an authorized emergency telecommunications service (ETS)for use by authorities to organize and coordinate emergency and disaster relief operations are described in [IEPREP Rqmts]. It provides a basis from which ETS can be negotiated to provide user-acceptable communications. The requirements relate to user expectation and are general, functional, and intended to provide wide latitude in implementation options. A framework for supporting authorized emergency related communication within the context of IP telephony has been presented in [IEPREP Frame]. The framework includes a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, a corresponding set of protocols and capabilities are presented which provide a more specific set of recommendations regarding existing IETF protocols. This current paper builds on the framework to provide specific guidance for implementing an ETS using existing protocols. This document makes a distinction between National Emergency applications and International Emergency applications based on the notion that different countries may require different ETS treatments for national versus international emergency applications. (In both cases, the applications are assumed to be within the context of authorized and authenticated uses for official purposes versus the more commonly considered public emergency service.) Within the USA, National Emergency telephony applications are recognized in SS7 call setup by the Initial Address Message (IAM) Calling Party Category (CPC) being set to the High Probability of Completion (HPC) codepoint as specified in [ANSI HPC]. When National Emergency applications are noted below, it is assumed that the call has been recognized as such by some mechanism like HPC. Similarly, the ITU is addressing how to signal international emergency calls [ITU IEPS] and the same assumption of recognition is applied. 1.1 Motivation The motivation for this draft is to initiate work on providing appropriate guidance to the international community on the design of Emergency Telecommunications Service (ETS) telephony applications using existing protocols. McGregor et al Expires December 23, 2003 [Page 3] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 1.2 Terms and Definitions The following acronyms are exploded for clarity: AT = Access Tandem CSN = Circuit Switched Network EF = Expedited Forwarding E-LSP = EXP-inferred-PSC LSPs ETS = Emergency Telecommunications Service EXP = field in MPLS label GW = Gateway (CSN to IP, or IP to CSN) LSP = Label Switched Path LSR = Label Switching Router MG = Media Gateway MGC = Media Gateway Controller MPLS = Multi-Protocol Label Swtiching PHB = Per Hop Behavior PSC = PHB Scheduling Class SG = Signaling Gateway STP = Signal Transfer Point TDM = Time Division Multiplexing 2. IP Bridging Topology The IP Bridging Topology is defined in [IEPREP Term] and is sometimes known as "IP in the Middle" of two CSNs. In this topology, a CSN phone of any type initiates (dials) a call to another CSN phone with an IP core between the two CSNs. This topology should simplistically look like this: McGregor et al Expires December 23, 2003 [Page 4] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 Circuit Internet Circuit Switched IP or IP Switched Network Ingress IP Segment Egress Network -----------+ +--------------+ +----------- | +----+ | IP | +----+ | CSN | | | | | | | | CSN Phone ------->| GW |----------------------->| GW |-------->Phone | | | | | | | | | +----+ | | +----+ | -----------+ +--------------+ +----------- Figure 1. Topology "IP Bridging" For the purposes of this document, the topology is further elaborated to explode the CSN elements into ATs and STPs, and to explode the IP segment into access and egress SGs, MGs, and MGCs, and to show core LSRs, as portrayed below in Figure 2. --------------+ +----+ +----+ +---------- | | | | | | STP.....|....|.SG | | SG.|....|....STP : | | : | | : | | : : | | : | +--------------+ | : | | : : | | MGC| | | | MGC| | : : | | : | | | | : | | : : | | : | | | | : | | : AT ------->| MG |------LSR -----LSR----->| MG |--------> AT | | | | | | | | | +----+ | | +----+ | -----------+ +--------------+ +----------- Figure 2. Exploded Topology "IP Bridging" This explosion is intended to portray a possible CSN Local Exchange Carrier transiting an IP Interexchange Carrier. Note that although the topology shows the SG connected directly to the MGC and the MGC connected directly to the MG, these connections should be viewed as logical connections physically formed by LSPs through the LSRs, with the SG, MGC, and MG all actually connected to the LSR. The baseline telephony application design for this topology is assumed to be bearer traffic from AT to MG and MG to AT via conventional TDM trunks and from MG to LSR to LSR to MG via LSPs providing EF PHB supporting RTP media exchange between the MGs. The signaling is assumed to be conventional SS7 [SS7] from AT to STP to SG and SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC. The MGC is assumed to signal with the MG using MEGACO [MEGACO], and signaling between the MGCs is assumed to be SIP [SIP] with telephony extensions [SIP-T]. McGregor et al Expires December 23, 2003 [Page 5] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 3. MLPS LSPs The recommended practice is to separate ETS traffic treatment from other traffic treatment by the use of a dedicated codepoint in E-LSPs to specify application of an ETS PHB versus dedicating LSPs to ETS. It is recognized that MPLS LSPs [MPLS] have very limited resources for traffic differentiation, and allocating a significant part of the resources for the nominally rare but occasionally heavy ETS traffic may be viewed as wasteful. However, the alternative of creating a separate ETS topology of LSPs presents greater difficulties because of the ubiquitous requirement for ETS support coupled with its rare use leading to significant maintenance and operating challenges. It is thought to be much more efficient and less painful to maintain an enhancement on commonly used LSPs than to maintain a complete set of duplicate LSPs. E-LSPs [MPLS Diff] are recommended as the basic MPLS resource between nodes for ease of maintenance and effective scaling. Within E-LSPs, assignment of PHBs to the eight Differentiated Services codepoints is a matter of local administration. The recommended practice is that one of the codepoints (6) be dedicated to an ETS PHB. The ETS PHB is not a standard PHB and hence is also a matter of local administration. It is suggested that an ETS PHB be documented for development as an RFC. 4. SIP SIP [SIP] has a Priority header field to indicate the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of "normal". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways, and hence is of limited relevance in configuring an ETS. The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined elsewhere. Consistent with the RECOMMENDED practice that the value of "emergency" only be used when life, limb, or property are in imminent danger, the recommended practices is that ETS calls be pecified as "emergency". As noted in [SIP Pri], currently SIP does not include a mechanism that allows a request originator to indicate to SIP element that it wishes the request to invoke resource prioritization. (The SIP Priority header field described above deals only with user perception.) To address this need, the referenced work in progress adds a SIP protocol element that labels certain SIP requests. In particular, a new SIP header field for communications resource priority, called Resource-Priority, is McGregor et al Expires December 23, 2003 [Page 6] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 documented. This header field, once achieving RFC status, MAY be used by SIP user agents, including gateways, to influence their treatment of SIP requests, including the priority afforded to ETS calls. For gateways interfacing to CSNs, the behavior translates into analogous schemes in the CSN, in both the CSN-to-IP and IP-to-CSN directions. The referenced work in progress describes the syntax of the Resource- Priority header field as follows: Resource-Priority _ "Resource-Priority" HCOLON Resource-value Resource-value _ namespace "." priority namespace _ alphanum / "-" priority _ alphanum / "-" Resource-Priority: namespace.priority The Resource-value parameter in the Resource-Priority header indicates the resource priority desired by the request originator. The resource value is formatted as "namespace" "." "priority value". The value is drawn from the namespace identified by the namespace token. Namespaces and priorities are case-independent ASCII. Each namespace has at least one priority value. Namespaces and priority values within each namespace are to be registered with IANA. This paper suggests support be given to the referenced work in progress and that an "ets" namespace be suggested for inclusion in it. The "ets" namespace would have priority values of 1,2,3,4,5,6 where 1 is the highest priority and 6 is the lowest priority. Priorities 1-5 are to be administered in alignment with the five priorities specified by the wireless community for Wireless Priority Service [WPS]. Priority 6 is to be used for all other calls. The alignment with the Wireless Priority Service will enable direct IP support for priority wireless call transport. Where wireless calls interwork with CSNs before reaching the IP transit network, the WPS priority signaling has not yet been definitized, although use of MLPP [MLPP] signaling appears to be attractive. The SIP is used to signal call setup between MGCs. Telephony extensions to SIP permit use of a telephone number URL in the "From" field, e.g., From: tel:123-456-7890 Currently work is in progress [SIP CPC] to add the Calling Party Category (CPC) as an extension to this form of url, permitting the SS7 CPC HPC value to be mapped as: McGregor et al Expires December 23, 2003 [Page 7] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 From: tel:123-456-7890;cpc=priority This work will greatly simplify call setup priority treatment of HPC calls providing a direct mapping of the SS7 IAM CPC parameter as part of SIP. To the extent that the SIP Resource Priority header provides an ETS priority, the url cpc parameter may appear redundant and more limited. However, the direct IAM – SIP parameter mapping is viewed as sufficiently valuable to justify independent support. The SIP url cpc parameter does not yet appear to have reached RFC status, and the general guidance on use of the telephone url is to disregard the url if any parameter is not recognized. Accordingly, it is suggested that support be given to standardizing the cpc parameter, but that it not be used until it is standardized. 5. MEGACO The MEGACO [MEGACO] protocol provides the means for the MGC to specify the interconnection of traffic between a TDM circuit and an RTP session at the MG. MEGACO includes a ContextRequest parameter for "priority" and a ContextRequest parameter (Boolean) to indicate "emergency". Both parameters are optional. The priority is used for a context in order to provide the MG with information about a certain precedence handling for a context. The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of contexts must be handled simultaneously. The "priority" parameter is specified to have a range of priority values 0-15. This ETS paper recommends the practice of the ETS using priorities 1-6 in alignment with the SIP Resource-Priority header and Wireless Priority Service conventions described in Section 4. Priority value 0 should be reserved. It is suggested that work be initiated to establish these assignments as standard. The indicator for an emergency call is provided to allow a preference handling in the MG. This ETS paper recommends the practice of applying the "emergency" indicator for ETS calls. 6. SDP Attributes When a call is initiated, the SDP is applied to describe the session request between MGCs and between the MGC and MG (as a MEGACO variant). The SDP [SDP] provides the means to ascribe to a session a set of attributes by use of the attribute parameter. Values (character strings) for the attribute parameter may be drawn from the set of standard values with corresponding standard interpretations, or be McGregor et al Expires December 23, 2003 [Page 8] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 chosen in accordance with local administration with local interpretation (as long as they do not conflict with a standard value). The recommended practice is to specify ETS sessions as either National Emergency sessions using the attribute parameter value "x-NatETS" (where the leading "x" is understood to be customary to designate non- standard values) or International Emergency sessions using the attribute parameter value "x-IntETS". It is suggested that an effort be initiated to standardize these attribute values. The rationale for including an ETS designation via the SDP attribute parameter is that certain session treatments may be influenced by recognition of the session as an ETS session and that inclusion in the session description can be more general in application than telephony. 7. Differentiated Services Code Points The Differentiated Services [Diff Serv] field of the IP packet has its range of codepoints divided into three pools, the second of which is designated for experimental and local use. The recommended practice is to assign two values from this pool to designate International Emergency and National Emergency service differentiations. More precisely, the following two values are recommended, subject to confirmation that they do not conflict with any other known assignments: National Emergency = 011111 International Emergency = 011011 It is suggested that work be initiated to standardize Differentiated Services codepoints for International Emergency and National Emergency traffic. It is recommended that the two Differentiated Services codepoints map into the common ETS MPLS Differentiated Services codepoint. The distinct IP level codepoints are expected to be of some use in providing differentiated services between the two types of traffic upon egress from (and possibly access to) the LSPs. (This will be more true in topologies other than the IP Bridging topology considered here.) It should be noted that Differentiated Services reflexivity is the subject or work in progress [IEPREP Reflex] and it is suggested here that such work be supported. 8. Signaling The signaling between the CSN segment and IP segment for the topology under consideration is SS7. To provide ETS service to calls signaled over this interface, either a designation mechanism must be applied in the SS7 IAM message, or the signaling must be known to relate to ETS calls (e.g., by virtue of the dedicated CSN ETS facilities over which McGregor et al Expires December 23, 2003 [Page 9] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 the signaling is arriving). Within the USA, the IAM Calling party Category (CPC) High Probability of Completion (HPC) codepoint is used to signal calls as ETS. When a SG receives a call recognized as an ETS call (e.g., by the IAM CPC HPC codepoint), it must signal this recognition to the MGC. It is recommended that this signaling be accomplished by use of the SS7 ISUP IAM message communicated over SS7 MTP3 over M2UA over SCTP over IP. The IAM being sent should apply the same mechanism as used to identify an ETS call as the IAM being received (e.g., the HPC codepoint). Similarly the MTP3 congestion priority assigned to the IAM being sent should be the same as the congestion priority on the IAM being received (e.g., in the USA, IAMs with HPC set have a congestion priority of 1 where all other IAMs have a lower congestion priority of zero). The IAM should be sent from the SG to the MGC over an E-LSP using the EXP ETS codepoint. 9. Security Considerations Where an ETS call is carried from PSTN to PSTN via one telephony carrier's backbone IP network, as considered here, very little IP- specific security support is required. The user is assumed to have authenticated his entitlement to ETS service in the originating CSN segment and the indication of the call as an ETS call across the CSN to IP interface is presumed to be without issue at this time. Conversely, the gateway back into the CSN must similarly signal the call as an ETS call. A secure link between the gateways may be set up using IPSec or SIP security functionality. 10. IANA Considerations This document introduces several names and values that can be locally administered, but which are suggested as considerations for IANA. In particular: - An SIP Priority Resource header namespace of "ets" and priority values of 1-6 be specified for ETS (assuming the work in progress becomes an RFC). - The MEGACO priority descriptor values 1-6 be assigned for ETS application. - SDP attribute values of "NatETS" and "IntETS" be specified. - Differntiated Services codepoints of National Emergency = 011111 and International Emergency = 011011 be specified. It is suggested that work be initiated to register such names and values with IANA. McGregor et al Expires December 23, 2003 [Page 10] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 Normative References [Diff Serv] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [IEPREP Term] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003. [MPLS diff] Le Faucheur, F. et al, "MPLS Support of Differentiated Services", RFC 3270, May 2002. [MEGACO] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., Marconi, Segers, J., "MEGACO Protocol Version 1.0", RFC 3015, November 2000. [M2UA] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., Heitz, J., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, September 2002. [MPLS] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", January 2001. [MPLS Diff] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [SCTP] Stewart, R., et al., "Stream Control Transmission Protocol", RFC2960, October 2000. [SDP] Handley, M., Jacobson, V., "SDP: Session Description protocol", RFC 2974, October 2000. [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [SIP Pri] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003. [SIP-T] Vemuri, A., Peterson, J., "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", RFC 3372, September 2002. McGregor et al Expires December 23, 2003 [Page 11] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 Non-Normative References [ANSI HPC] ANSI, "Signaling System No. 7(SS7) High Probability of Completion (HPC) Network Capability, ANSI T1.631-1993, (R1999). [IEPREP Frame] Carlberg, K., Brown, I., Beard, C., "Framework for Supporting ETS in IP Telephony", Work in Progress, Internet-Draft, October 2002. [IEPREP Reflex] Atarashi, R., Baker, F., "Reflexive DSCP Policy", Work in Progress, Internet-Draft, October 2002. [IEPREP Rqmts] Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", Work in Progress, Internet- Draft, January, 2003. [IEPREP IP Rqmts] Carlberg, K., Atkinson, R., "IP Telephony Requirements for Emergency Telecommunications Service", Work In Progress, Internet- Draft, January, 2003. [ITU IEPS] "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002. [ITU MLPP] ITU, "Multi-Level Precedence and Preemption Service, ITU Recommendation I.255.3, July, 1990. [SIP CPC] Peterson, J. "The Calling Party's Category tel URL Parameter", Work in Progress, Internet-Draft, October 27, 2002. [SS7] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, September 1997, . [ISUP SIP] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP Mapping", Work in Progress, Internet-Draft. McGregor et al Expires December 23, 2003 [Page 12] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 Appendix A. Notes Appendix B. Acknowledgments Authors' Addresses Pat McGregor Nyquetek Inc 8397 Piping Rock Millersville, MD 21108 USA EMail: pat_mcgregor@msn.com Phone: 410-703-4486 Richard Kaczmarek Nyquetek Inc c/o CSC 15000 Conference Center Dr Chantilly, VA Email: Richard.Kaczmarek@DynCorp.com Phone: 703-818-5894 Dennis Berg CSC 15000 Conference Center Dr Chantilly, VA Email: Dennis.Berg@DynCorp.com Phone: 703-818-4608 Janet Gunn CSC 15000 Conference Center Dr Chantilly, VA Email: Janet.Gunn@DynCorp.com Phone: 703-818-4725 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 McGregor et al Expires December 23, 2003 [Page 13] Internet-Draft IEPREP IP Bridging MPLS BCP June 2003 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. McGregor et al Expires December 23, 2003 [Page 14]