INTERNET-DRAFT M. Ylianttila Internet Engineering Task Force Juha-Pekka Makela Issued: 11 April 2000 University of Oulu, Finland K. Pahlavan Worcester Polytechnic Institute, USA Considerations on IP Spatial Location Protocol Requirements Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Conventions used in this document The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Abstract This document addresses those requirements for IP spatial location protocol that emerges from the situation where mobile hosts (MH) use location information in the inter-domain mobility management. While IP spatial location protocol has many other usage cases, this document focuses on the requirements for mobile IP device that needs to know the whereabouts of IP subnetwork to be visited in order to prepare for handoff. Three inter-technology handoff (ITHO) scenarios and the related problems are presented, and the requirements for the system architecture, terminal and IP spatial location protocol are outlined. Ylianttila [Page 1] Internet Draft April 2000 TABLE OF CONTENTS ...................................................2 1. Introduction .....................................................2 1.1 Scope ..........................................................3 1.2 Abbreviations ..................................................3 2. Inter-technology Handoff Scenarios ...............................3 2.1 Moving-in (MI) Scenario ........................................3 2.2 Moving-out (MO) Scenario .......................................4 2.3 Moving-through (MT) Scenario ...................................4 2.4 Related Problems ...............................................4 3. System Architecture Requirements .................................5 3.1 Geolocation Data Source ........................................5 3.2 Secure Coordinate Server .......................................5 3.3 Terminal Velocity and Updating Frequency .......................5 3.4 Geolocation Accuracy ...........................................6 3.5 Inter-Working Functions ........................................7 3.6 MI Scenario Requirements .......................................7 3.6.1 Checking Resolution of LPN beacon ...........................7 3.6.2 Transition Time .............................................7 3.6.3 Transition Region ...........................................7 3.6.4 Initiation Distance .........................................8 3.7 MO Scenario Requirements .......................................8 3.7.1 Straight-forward Approach ...................................8 3.7.2 Multiple-metric Approach ....................................8 3.7.3 Statistical Approach ........................................9 3.8 MT Scenario Requirements .......................................9 4. Terminal Requirements ............................................9 4.1 Algorithm Inputs ..............................................10 4.2 Algorithm Outputs .............................................10 4.3 Example Algorithm .............................................10 5. Requirements for the IP spatial Location Protocol ...............11 6. References ......................................................12 7. Acknowledgements ................................................13 8. Author's Addresses ..............................................13 1. INTRODUCTION In personal communication systems, providing mobility between dissimilar (e.g. fast indoor and slower outdoor) networks is one of the most interesting areas of research today [1,2]. This kind of inter-technology mobility is seen as one of the central issues in the becoming fourth generation of telecommunication networks and systems. IP is seen as the interconnecting protocol, and various schemes for IP mobility management has been introduced, both in micro and macro level [3,4]. Another trend is the integration of geolocation capabilities to the existing networks. Location services (LCS) are to be specified in the 3G [5-9] and other networking related standardisation, also within IETF [10-17]. These features bring added value for the industry, network operators and mobile users. An interesting area that has not yet been addressed is the interplay between these two: how to use geolocation information in the inter-technology (inter-domain) mobility management. Ylianttila [Page 2] Internet Draft April 2000 1.1. Scope This document addresses those requirements for IP spatial location protocol that emerges from the situation where mobile hosts (MH) use location information in the inter-domain mobility management. While IP spatial location protocol has many other usage cases, this document focuses on the requirements for mobile IP device that needs to know the whereabouts of IP subnetwork to be visited in order to prepare for handoff. Three inter-technology handoff (ITHO) scenarios and the related problems are presented, and the requirements for the system architecture, terminal and IP spatial location protocol are outlined. Considerations on the algorithm are given. The work is done in association with other spatial location related studies within IETF. 1.2. Abbreviations DGPS - Differential GPS GCI - Geolocation Coordinate Information GPS - Global Positioning System GPN - Global Positioning Network (e.g., GPS integrated with cellular) ITHO - Inter-technology Handoff IWF - Inter-working function LPN - Local Positioning Network (e.g., WLAN with geolocation) MH - Mobile Host MI - Moving-in MO - Moving-out MT - Moving-through QoS - Quality of Service RSS - Received Signal Strength SCS - Secure Coordinate Server SNR - Signal-to-Noise Ratio WLAN - Wireless Local Area Network 2. Inter-technology Handoff Scenarios There can be seen different business and usage scenarios around inter-technology mobility. In the following, three scenarios and the related problems are described. 2.1 Moving-in (MI) Scenario For some mobile Internet users the primary (underlay) network is the cellular network (i.e., GPN, when GPS or some other geolocation technology is integrated into cellular). It can be overlaid with a WLAN or some other short-range radio network (i.e., LPN when geolocation is enabled) in areas such as business centers, hotels, airports, etc, to provide higher data rate service. To avoid unnecessary search of LPN beacon mobile host (MH) must be aware of the whereabouts of the overlay system to be visited. Ylianttila [Page 3] Internet Draft April 2000 2.2 Moving-out (MO) Scenario LPN can be the primary (underlay) network for people who work in the office environment. In this scenario the user has a laptop in his (or her) office connected to the companies LPN. When he leaves his office, he may want to maintain the network connection alive (having some application, such as ftp or newsgroup, running). As LPN most probably provides greater data rate with less expense than the overlaying GPN, the user wants to maintain the LPN connection as long as possible before switching to the overlaying GPN data service. 2.3 Moving-through (MT) Scenario Here a fast moving MH (inside a moving vehicle) using GPN network is assumed to drive through a LPN coverage area. This is a combination of first two scenarios. 2.4 Related Problems Problems for MI scenario: 1) What kind of system architecture is needed to inform MH that it is approaching LPN or MH can make queries of nearest LPNs? 2) What are the requirements for IP spatial location protocol (ISL)in proportion to a) terminal velocity b) geolocation accuracy c) coordinate information updating frequency d) the time required for execution of inter-working and other related mobility management functions? 3) How is the terminal velocity concluded/acquired and indicated? 4) How is the geolocation accuracy indicated? 5) What is the structure of IP spatial location protocol that would take into consideration the requirements that emerge from ITHO mobility management usage scenarios? Problems for MO scenario: 6) How can MH exploit the LPN connection as far as possible in a seamless manner taking into consideration a) the different application types (real-time and non-real-time) b) time-varying radio channel (RSS)? c) other possible parameters to improve handoff performance? Problems for MT scenario: 7) What are the requirements for the LPN coverage area size in proportion to a) terminal velocity b) the amount of data to be transmitted during the visit to LPN? Ylianttila [Page 4] Internet Draft April 2000 With these defined three scenarios, there are many similar problems, as addressed in the context of MI scenario. However, terminal path and velocity can be different, as well as the channel model. For example, in MI and MO scenarios, we can think about a pedestrian coming and leaving his office environment. This means a handoff between indoor and outdoor radio channel. It also means a handoff between indoor and outdoor geolocation methods. In MT scenario, we can think about car driving through a LPN coverage area, from which MH can download a large data file, which would take much longer to download by using cellular data connection. 3. Requirements for the System Architecture 3.1 Geolocation Data Source In the future there will be multiple ways to provide geolocation information for MH. Both cellular and WLAN networks will eventually have geolocation capabilities. GPS or some other geolocation technology can be integrated with cellular terminals. On the other hand, broadband short-range radio systems such as WLANs will very likely support geolocation in the future (also indoors, where GPS does not work). In this document we refer these systems as Global Positioning Network (GPN) and Local Positioning Network (LPN) respectively. Within these networks, there should be a way for MH to choose the best (most accurate) geolocation data source as well as the best networking technology (highest data rate) available in a seamless manner for the mobile user. 3.2 Secure Coordinate Server MH can either allow or deny the routing of its location information to the distributed geolocation coordinate servers. Due to the fact that the transport and access to location information must be strictly authenticated and otherwise secured, these network nodes are referred in this document as Secure Coordinate Servers (SCS). It can also be referred as IP Spatial Location Server or whatever name is decided to be used. Here we just assume that this node exists and communication between it and MH can be established in a secure manner. A specific protocol to establish and deliver the geolocation coordinates, such as IP spatial location protocol can be used. Details of these are addressed in other spatial location related Internet drafts [10-17]. 3.3 Terminal Velocity and Updating Frequency Terminal velocity can be also used as a metric for the ITHO algorithm and application development. It can be calculated from two consecutive coordinate measurements. If the updating frequency of the coordinate information is f, and the distance between two measurement points (x1 and x2) is s, then terminal velocity is simply: Ylianttila [Page 5] Internet Draft April 2000 v = f*s (1) Consequently, the updating frequency is f = v/s (2) 3.4 Geolocation Accuracy Estimate of the current location of MH is effected by the geolocation accuracy E of the used technology. We can approximate that MH is moving To horizontal direction and Ex = E. Thus, distance between measurement points observed by MH is s = x2 - x1 +- 2E (3) By combining (2) and (3), we get a requirement for updating frequency as a function of terminal velocity and geolocation accuracy: f = v/(x2 - x1 +- 2E) (4) If some form of velocity vector will be specified (including the speed and direction of movement), it could be calculated from two consecutive location coordinates s= x2 - x1, and v=s/t (t= updating frequency). This estimate would be effected by the geolocation error, s = x2 - x1 +- 2E, where E is the maximum geolocation error. The following figure illustrates the worst case situation (in horizontal axis) +<- E ->+<- s ->+<- E ->+ x1' x1 x2 x2' Figure1. Worst case situation in velocity measurement In measurement point x1, due to the geolocation error, system would say that the terminal is in x1', and in x2 in x2', respectively. Thus the maximum error for this measurement would be 2E. Parameter E is different for different location systems. Thus, the accuracy field could indicate some specied class of accuracy. Application could then decide based on that whether it can use the current source of coordinate information for some specific actions. There can of course be some other ways to conclude terminal velocity. As a numerical example, if we assume f = 1/s (as in GPS), v = 1 m/s (pedestrian) and E = 0,1 m (DGPS), then x2 - x1 = 1 +- 0,2 m. Similarly, if v = 30 m/s (car driving), then x2 - x1 = 30 +- 0,2 m. We can conclude that when v is high, then the proportional effect of E to the measured geolocation is less, and vice versa. MH may extrapolate (if needed) the terminal path between consecutive measurements to give a more accurate estimate of the current location between two points of measurements. Ylianttila [Page 6] Internet Draft April 2000 3.5 Inter-Working Functions As all traffic is here assumed to be IP based, micro- and macromobility schemes addressed in the Mobile IP working group can be utilized. The terminal algorithm can be used in the terminal to monitor the network resources, and then trigger IWF functions when needed. The study of the performance of IWF schemes when geolocation information is used is an interesting topic, but is out of the scope of this document. 3.6 MI Scenario Requirements During and before the time that MH is visiting the LPN, it should associate itself with LPN, trigger the needed IWF and ITHO algorithms and execute the requested data transfer actions. For mobility management in MI scenario, geolocation information can be obtained from GPN and used in the following way. Some of the issues mentioned here are also relevant for the two other scenarios. 3.6.1 Checking resolution of LPN beacon The resolution of checking must be determined so that the battery of the MH will not be consumed unnecessarily when the MH is far away from the LPN. Therefore, different levels of checking resolution may be used within different distances from the LPN coverage area edge, also depending on the terminal velocity vector (speed/direction). 3.6.2 Transition Time Transition time t(itho) is the time needed to bring up the interface, associate with LPN system, trigger and perform the inter-working functions (IWF) such as Mobile IP registration procedure. It also includes the possible additional network delay caused by e.g. traffic congestion. It begins when the first burst of LPN beacon is received in MH. It ends when MH is associated with LPN and the first bytes of data are sent through LPN. When MH leaves LPN, there is a similar but reverse order procedure: de-association from LPN, association to GPN, etc. [1,2]. 3.6.3 Transition Region Transition region Dtr is the distance what MH moves during t(itho). If we assume that MH is moving with constant velocity v (m/s), then Dtr = v*t(itho) (5) The total delay budget of t(itho) must be taken into consideration in system design, e.g. when dimensioning the LPN coverage for fast moving hosts (MT scenario). Ylianttila [Page 7] Internet Draft April 2000 3.6.4 Initiation Distance To allow MH to prepare for ITHO, MH must get a message from SCS that it is approaching the LPN hot spot area. It should prepare to ITHO and to trigger ITHO procedure exactly when it gets the first bursts of the transmission channel. Due to the geolocation error, MH has to start active scanning in point D (initiation distance from the edge of LPN coverage area). For D, there is a requirement: D >= Dtr(max) + E(max) (6) where Dtr(max) is the maximum value of expected transition region (5) and E(max) is the maximum of estimated geolocation error in GPN. Only when this requirement is met, the geolocation information becomes handy beyond statistical variance and allows MH to prepare for ITHO in all circumstances. 3.7 MO Scenario Requirements Here we assume that both GPN and LPN interfaces are activated. In case MH stays a long time in LPN, then GPN interface can be deactivated and reactivated similar to MI scenario. For mobility management in MO scenario (from LPN to GPN), geolocation information can be used in either of the following ways. 3.7.1 Straight-forward Approach A simplistic approach for MO scenario is to just employ RSS in the algorithm. When RSS goes below the defined value, the algorithm triggers ITHO algorithm to switch from LPN to GPN. This way, however, the range of LPN may not be fully utilised. For a non-real-time application, such as ftp, it would be preferable to stay in LPN as far as possible, through the whole transition region till no data goes through LPN connection. This may cause a serious gap to real-time traffic. But non-real-time application will gain about this by getting more data through LPN that it would have got through GPN during the same time interval (we can think LPN to have at least 2 Mbit/s and GPN about 56 kbit/s data rates). 3.7.2 Multiple-metric Approach In this approach, Geolocation Coordinate Information (GCI) or any number of other valid metrics can be given as input for a multiple-metric ITHO algorithm. This way LPN range may be utilized in seamless manner. ITHO should take place in early enough location, where the handoff delay will not cut off real-time traffic (especially when adequate buffering is used). Ylianttila [Page 8] Internet Draft April 2000 3.7.3 Statistical Approach Ideal system would use the geolocation history and other information to adapt itself to perform the best possible manner in the specific environment. Statistics of the locations and related RSS values when ITHO takes place could be collected to SCS. MH could store the coordinates where ITHO handoff last occurred to SCS together with related link specific values such as RSS and SNR. For the algorithm input, MH can acquire GCI from SCS databases that hold the information of location and dynamic range of LPN. 3.8 MT Scenario Requirements In MT, which is a combination of MI and MO scenarios, the requirements presented for them apply also here. In addition to them, based on the terminal velocity and LPN network traffic status, the system could inform how much data (B) can be transmitted during driving through LPN (throughput h). Trivially, t =(B/h) (7) and if the radius of LPN is r, then v =(2r/t) (8) and from this we can easily calculate the maximum amount of data that can be transmitted (B): B <= 2rh/v (9) If r is know by the system (SCS), it could suggest for example to slow down to certain velocity v in order to have time t to download a specific requested large data file of size B (such as audio or video file). 4. Terminal Requirements Many requirements for the terminal have been already given in the context of the requirements for system architecture. Naturally, MH must have interfaces to both GPN and LPN networks, thus making it dual-mode (or multiple-mode). It should support IP based traffic (also IPv6), security and adequate QoS policies for variety of applications. There may be several types of terminals with different requirements, but that is out the scope of this document. For the mobility management part, complexity of mobility and network management must be transparent to the user as far as possible, hence making the use of mobile terminals flexible and convenient. User may configure if he denies or allows Ylianttila [Page 9] Internet Draft April 2000 forwarding of his location data to SCS for some other purpose than inter-technology mobility management. In the following some considerations on the ITHO algorithm are given. 4.1 Algorithm Inputs As mentioned earlier, GCI can be given as an input to a multiple-metric ITHO algorithm together with other valid metrics. For our ITHO algorithm we consider three input parameters: Received Signal Strength (RSS), CGI, MH Velocity (MHV). As an additional parameter, Real-time factor (RTF) could be used to indicate the realtimeness of the transmitted data. Terminal may utilize either one or more of these inputs to be used in the algorithm, as was described in section 3.7. 4.2 Algorithm Outputs ITHO algorithm can give one or more action outputs. The output can either be a direct command to perform the handoff, or indicate the state of the system in order to make additional arrangements for the mobility management. As an example, we can consider ITHO algorithm for MO scenario, giving one of the three possible action outputs: A, B and C. For a MH working in LPN underlay the output A (Rest) indicates that the link quality of the LPN is satisfactory and there is no handoff imminent. Output B (Alert) indicates that there is an increased possibility of handoff in the near future and gives the system a chance to prepare for a handoff procedure. The C (Handoff) output indicates that a handoff is needed and the handoff procedure to the GPN is invoked. Similar approach can be applied to other scenarios as well. 4.3 Example Algorithm As an example, fuzzy logic algorithm can be used to handle multiple metric decision. There are also other alternatives, as mentioned in [18]. Fuzzy logic system contains four main parts: Fuzzyfier, Rule base, Inference Engine and Defuzzyfier. Engine maps the fuzzyfied input by if-then reasoning process to the fuzzy output variable, which is then defuzzyfied to form a crisp output value. Table 1. Rule base for ITHO algorithm based on fuzzy logic. Rule If And And Then No. RSS MHV GCI ITHO 1 Weak Slow Far Rest 2 Medium Medium Far Rest 3 Strong Fast Far Alert 4 Weak Slow Close Alert 5 Medium Medium Close Handoff 6 Strong Fast Close Handoff Ylianttila [Page 10] Internet Draft April 2000 Example of the Rule base for ITHO can be seen on Table 1. Only six of total 27 different combinations are presented. When we elaborate for example rule 1, we see that if the RSS from the LPN is weak and MHV is slow and GCI indicates that MH is far from the LPN, then ITHO is in a rest state. That indicates that there is no handoff imminent and the battery power should not be wasted for unnecessary search. Fuzzy concepts such as weak, low, far are defined by membership functions. For example triangular and trapezoidal membership functions can be used to tailor for the RSS fuzzy concepts weak, medium and strong to match to the geometry of the environment. 5. Requirements for the IP spatial Location Protocol The problem statement in Spatial Location BOF in Adelaine 47th IETF was defined as: "Secure and Reliable Exchange of Location Information between IP devices". In this, however, the focus should merely be in exchance of location information rather than in the security issues, although security MUST be build into the system. Our suggestion is that IP spatial location protocol MUST be application layer protocol. Then, location information is just data in certain format that will be delivered in secure manner. We can then use strong encryption in the application layer, and other security mechanisms in the underlaying layers. We do not see any additional security requirements for location data than any other important data. We may only want to define the level of security needed, e.g., encryption key lenght. This level may be different for different applications that utilise location information. One requirement that should be included in the IP spatial location protocol is some sort of QoS field for different types of coordinate flows. Some, such as for some Virtual Reality applications, may require constant bit rate, where some other applications do not have such requirements. QoS field would help to differentiate these different flows and mapping to the underlaying protocols would be easy. As a conlusion, based on the discussion in ext-ip-location@research.nokia.com mailing list and ideas presented in [10-17], IP spatial location protocol should contain the following fields: - Location of the device (format to be decided) - Time stamp (can be used to determine the validity of the coordinate information, whether it is "out of date" or not) - Updating frequency (terminal can request certain rate) - Security classification field (different classes of security) - QoS field (e.g. based on ATM QoS classes) - Accuracy field (i.e. class of estimated/expected maximum error) The work to identify the details of the protocol will continue in the framework of Spatial Location activities within IETF. Ylianttila [Page 11] Internet Draft April 2000 6. References [1] M. Ylianttila, R.Pichna, J. Vallstr÷m, J. M„kel„, A. Zahedi, P.Krishnamurthy, K. Pahlavan, "Handoff Procedure for Heterogeneous Wireless Networks", Globecom'99, Future Wireless Communication Systems Symposium, Rio De Janeiro, Brazil, December 1999. [2] A. Hatami, P. Krishnamurthy, K. Pahlavan, M.Ylianttila, J. M„kel„, R. Pichna, "Analytical Framework for Handoff in Non-Homogeneous Mobile Data Networks", PIMRC'99, Osaka, Japan, September 1999. [3] C. Perkins, "IP Mobility Support", RFC2002 (Proposed Standard), Internet Engineering Task Force, October 1996. [4] A. Campbell, J. Gomez, C-Y. Wan, S. Kim, Z. Turanyi, A. Valko, "Cellular IP", Interner Draft, draft-ietf-mobileip-cellularip- 00.txt, January 2000 (work in progress). [5] GSM 03.32, GSM LCS Specification, ETSI. [6] 3GPP TS 22.071 Location Services (LCS); Service description, Stage 1. [7] 3GPP TS 23.171 Functional stage 2 description of location services in UMTS. [8] 3GPP TS 23.032, Universal Geographical Area Description (GAD). [9] 3GPP TS 23.171 Functional stage 2 description of location services in UTRAN. [10] C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, "DNS Encoding of Geographical Location", RFC1712, November 1994 [11] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC1876, January 1996. [12] E. Guttman, C.Perkins, J. Veizades and M. Day, "Service Location Protocol, Version 2", RFC2608, June 1999. [13] P. Faltstrom, D. Gulik "The People Location Protocol", Internet Draft, draft-faltstrom-plop-01.txt, April 1997 (work-in-progress). [14] H. Tang, J. Ruutu, J. Loughney, "Problems and Requirements of Some IP Applications Based on Spatial Location Information", Internet Draft, draft-tang-islf-req-00.txt, February 2000 (work-in progress). [15] S. Nyckelgard, J. Loughney, "ISL Architectural Considerations", Internet Draft, draft-nyckelgard-isl-arch-00.txt", March 2000 (work-in-progress). Ylianttila [Page 12] Internet Draft April 2000 [16] M. Korkea-aho, "Some Scenarios for an ISL Architecture", Internet Draft, draft-korkea-aho-isl-scenarios-00.txt, March 2000 (work-in- progress). [17] J.Polk, H. Tang, "Spatial Location Protocol Location Server Authentication", Internet Draft, draft-polk-slp-loc-auth-server- 00.txt, March 2000 (work-in-progress). [18] N. Tripathi, "Generic Adaptive Handoff Algorithms using Fuzzy Logic and Neural Networks", Ph.D Thesis, Virginia Polytechnic Institute and State University, August 1997, 262 p. 7. Acknowledgements The acknowledgments are due to the project team of WINGIP (Wireless Indoor Geolocation and IPv6 traffic analysis). The authors would like to thank TEKES, Nokia and Finnish Defense Forces for supporting financially this project. Special acknowledgement is given to Dr. Roman Pichna at Nokia for his contributions throughout the project. 8. Author's Addresses Mika Ylianttila Centre for Wireless Communications Tutkijantie 2E, PO Box 4500 FIN-90014 University of Oulu, Finland e-mail: mika.ylianttila@oulu.fi Juha-Pekka Makela Centre for Wireless Communications Tutkijantie 2E, PO Box 4500 FIN-90014 University of Oulu, Finland e-mail: juha-pekka.makela@ee.oulu.fi Kaveh Pahlavan Center for Wireless Information Networks Studies Worcester Polytechnic Institute Worcester, MA 01609, USA e-mail: kaveh@ece.wpi.edu Ylianttila [Page 13] Internet Draft April 2000 Copyright (C) The Internet Society (2000). 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 organi- zations, 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. The Expiration date for this Internet Draft is: December 11, 2000 Ylianttila [Page 14]