Internet Draft R. Jayaraj Document: draft-rjaya-seamoby-cslist-ind-00.txt ICR, NUS Expires: November 2002 May 2002 Cell-Search List Indications for Seamless Anticipative, Resource-Mindful Handovers 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 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 In 802.11 or similar technologies, the network device enters a æcell-search modeÆ when the signal level/quality of the serving AP drops below a certain value. In the cell-search mode, the device actively measures the signal level and/or quality of neighbouring APs in addition to that of the serving AP. This document describes how the use of MN originated cell-search list indications, which carry signal level and signal quality measurements of access points in the immediate vicinity of the mobile node, can assist in a handover scheme that factors in seamlessness, target router selection, context transfer and resource usage information. R.Jayaraj Expires - November 2002 [Page 1] Internet Draft Cell-Search List For Handover May 2002 Table of Contents 1. Terms and Abbreviations Used..................................2 2. Introduction..................................................3 3. Underlying Framework..........................................4 4. The Cell-Search List Indications..............................6 5. Configuring the Cell-Search Threshold and List Indication.....9 6. The WIF-SAP..................................................11 7. Suggested Message Structures.................................12 7.1 Cell-Search and List Indication Configuration Command....12 7.2 Cell-Search List Indication (CSLIST-IND).................12 7.3 Handover Command (HO-CMD)................................13 8. Security Considerations......................................14 9. Scalability Considerations...................................14 References......................................................14 Author's Contact Information....................................15 1. Terms and Abbreviations Used AP - Access Point AR - Access Router BET - Bi-directional Edge Tunnel CTX - L3 Context information. EAP - Edge Access Protocol HM - Handover Management Entity IARP - Inter Access Router Protocol IE - Informational Elements L2 - Layer-2 L2P - Layer-2 Protocol. L3 - Layer-3 L4 - Layer-4 MN - Mobile Node nAP - New Access Point nAR - New Access Router oAP - old Access Point oAR - old Access Router RA - (IPv6) Router Advertisement RM - Resource Management Entity SLEV - Signal Level SQUA - Signal Quality WIF - Wireless Interface WIF-SAP û Wireless Interface Service Access Point R.Jayaraj Expires - November 2002 [Page 2] Internet Draft Cell-Search List For Handover May 2002 2. Introduction Mobile-IP protocols ([2002],[MIP6]), define how an MN can change its L3 point of interface to networks and yet maintain ongoing L4 sessions. They are particularly important in wireless LAN environments consisting of multiple subnets. Related to these protocols is the concept of network-initiated pre- handover mobile-IP binding/registration, where the MN performs mobile-IP binding/registration procedures with new ARs while it is still on the old link ([LOWLATENCY], [FASTMIP6]), so that the change is seamless. Context transfer refers to the transfer of state from an oAR to a nAR as the mobile handovers from an old subnet to a new subnet. This state corresponds to L2/L3 security and QoS/resource configurations maintained by the oAR as a policy enforcement point for the MN ([CTX], [CTXREQ]). In 802.11 or similar technologies, the WIF enters a æcell-search modeÆ when the signal level/quality of the serving AP drops below a certain value. In the cell-search mode, the WIF actively measures the signal level and/or quality of neighbouring APs in addition to that of the serving AP. In a seamless, anticipative and resource-mindful IP handover scheme, the network intelligently determines the target access router among candidate routers, transfers the mobile nodeÆs context from the old router to this new router, and forwards Layer-3 handover information associated with this new router to the mobile node before it performs a Layer-2 handover. In this wise, the overall handover latency as experienced by the MN is effectively reduced to the latency of the Layer-2 handover. The following sections describe how the use of MN originated cell- search list indications, which carry signal level and signal quality measurements of access points in the immediate vicinity of the mobile node, can assist in a handover scheme that factors in seamlessness, target router selection, context transfer and resource usage information. The concept of a wireless MN indicating signal level/quality measurements of neighbour cells to the network is not new; it has been used before in [GSMRR]. R.Jayaraj Expires - November 2002 [Page 3] Internet Draft Cell-Search List For Handover May 2002 3. Underlying Framework To describe the utility of the cell-search list indications, we must first describe an architecture for managing network-controlled seamless, anticipative & resource-mindful handovers over which it may be viable. An example of such an architecture is shown in Fig 1. ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `+-----------+ +-----------+ +-----------+` `| MN | | oAR | | nAR |` `| +--------+| | +--------+| IARP | +--------+|` `| | RM || | | RM +-----------+ RM ||` `| | +----+|| EAP | | +----+|| | | +----+||` `| | | HM +---------------+ HM ||| | | | HM |||` `| | ++--++|| | | +-+--+|| | | +-+--+||` `| +---|--|-+| | +----|---+| | +----|---+|` `| | | | | | | | | |` `| |+-+-+| | +-+--+ | | +-+--+ |` `| ||IP || | | IP | | | | IP | |` `| |+-+-+| | +-+--+ | | +-+--+ |` `WIFSAP| | | | | | | | |` `| ++--+-+ L2P+---+| L2P+-+--+ | +---+| L2P+-+--+ |` `| | WIF +----+oAP+-----+ IF | | |nAP+-----+ IF | |` `| +-----+| +---+| +----+ | +---+| +----+ |` `+-----------+ +-----------+ +-----------+` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` Fig 1 Example architecture for managing anticipative & resource- mindful handovers In this example, we assume that handover is managed distributedly amongst ARs. Each AR has a resource management entity (RM) that communicates with its peers on neighbour ARs via an IARP. Typically, the ARs communicate resource usage information via RES-STAT-IND primitives as shown in Fig 2, at some intervals. Due to the sampling effect, this information is only statistically accurate to a certain confidence level. Within each RM is a handover management entity (HM) that acts as a coordinator of handovers. Between the MN and an AR, a L3 EAP exists to perform access registration and host configuration, e.g. [DHC6]. R.Jayaraj Expires - November 2002 [Page 4] Internet Draft Cell-Search List For Handover May 2002 ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `nAR1|nAP1 oAR|oAP nAR2|nAP2 ` ` -+- -+- -+- ` ` : : : : : : resource` ` : : : : : : update ` ` | | | | | | timeout ` ` | | RES-STAT-IND |<-+ ` ` |<-+---------------+<-+---------------+ ` ` | | | | +--+ ` ` : : resource : : : : ` ` : : update : : : : ` ` | | timeout | | | | ` ` |<-+ RES-STAT-IND | | ` ` +----------------->+--+-------------->| | ` ` +--+ | | | | ` ` : : : : resource | : ` ` : : : : update | : ` ` | | | | timeout | | ` ` | |RES-STAT-IND |<-+ RES-STAT-IND | | ` ` |<-+---------------+----------------->| | ` ` | | +--+ | | ` ` : : : : : : resource` ` : : : : : : update ` ` | | | | | | timeout ` ` | | RES-STAT-IND |<-+ ` ` |<-+---------------+<-+---------------+ ` ` | | | | +--+ ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` Fig 2 ARs exchange resource usage information at regular intervals On each MN, a HM entity exists on an orthogonal plane that intersects with the TCP/IP plane at the IP and L2/MAC layer. It utilises the EAP to send and respond to handover management messages to and from its peer on the AR. The HM acts as a L2-L3 synchronising handover coordinator on the MN, in terms of gathering relevant information from or configuring the WIF via the WIF-SAP, and configuring the IP layer synchronously. The WIF is a network device attached to the lower edge of IP, and hence its protocol stack is only defined up to the L2/MAC layer, e.g. 802.11. It exports the WIF-SAP, which is a set of well defined programming interfaces to obtain status information on and configure the L2/physical link that the WIF attaches to. R.Jayaraj Expires - November 2002 [Page 5] Internet Draft Cell-Search List For Handover May 2002 4. The Cell-Search List Indications We now describe the use of the cell-search list indications and its ramifications in a handover scenario. In this scenario, distributed handover control is assumed, where each AR performs the router selection, context transfer and IP handover functions. We assume the MN is in the vicinity of three APs, oAP, nAP1 and nAP2 which also act as, or are on three subnets on which are, three ARs, oAR, nAR1 and nAR2, respectively. The MN is initially attached to oAP and shares some context with oAR. a) Due to some pre-configured trigger event, e.g. a neighbour AP's signal level going over the serving AP's signal level plus hysteresis (0), the MN starts a process which sends CSLIST-IND messages to the oAR at certain intervals, reporting on the signal level and/or signal quality of oAP, nAP1 and nAP2 (1b). These lists act as indications to the network of APs that are handover candidates in view of their signal level and/or quality. b) On receipt of this primitive, oAR determines if a handover is required. Assuming the oAR maintains topological information on the connectivity of neighbouring APs and ARs, and has a rough idea of the current state of network resources used in the vicinity, then the oAR can form a list of candidate ARs that it can attempt to handover the MN to, if a handover is required (2). The decision on whether to perform a handover, and the selection of candidate ARs, may be based on one part or a combination of the following criteria: i) In terms of signal level/quality, the neighbour AP/AR(s) can serve the MN better than the current serving AP/AR, hysteresis accounted. ii) In terms of network resources, it is discovered that some neighbour AP/ARs are under-utilised, and the network wishes to perform load-balancing. iii) In terms of policy, the MN is a better paying customer and should be moved to an æexclusiveÆ, overlapping set of AP/ARs providing better service, or the MN is a lower paying customer and should be moved to a lower grade connection. iv) In terms of predicted direction and velocity of the MN, (based on time sequence samples given by the measurements), the neighbour AP/AR(s) have cell position and size characteristics that better suite the MN. R.Jayaraj Expires - November 2002 [Page 6] Internet Draft Cell-Search List For Handover May 2002 ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `MN oAR|oAP nAR1|nAP1 nAR2|nAP2` `-+- -+- -+- -+- ` ` : : : : ` ` +--+ 0./* cell search | | ` ` | | triggered */ | | ` ` |<-+ | | | ` ` | 1b.CSLIST-IND | | | ` ` +----------------->| | | ` ` : : : : ` ` : /* cell search list indication interval */ : ` ` : 1b.CSLIST-IND : : : ` ` +----------------->| | | ` ` | +--+ 2./* determine| | ` ` | | | candidate ARs */ | ` ` | 1b.CSLIST-IND |<-+ | | ` ` +----------------->| 3a.HO_REQ(oCtx) | | ` ` | +----------------->| | ` ` | | 3b.HO_REJ | | ` ` | 1b.CSLIST-IND |<-----------------+ | ` ` +----------------->| 4a.HO_REQ(oCtx) | ` ` | +------------------+----------------->| ` ` | | 4b.HO_CNF(nRA2,nCOA2) | ` ` | |<-----------------+------------------+ ` `5a.HO_CMD(nAP2,nCOA2,nRA2) | | ` ` |<-----------------+ | | ` ` | | | | ` ` +--+ 5b./* L2 | | | ` ` | | handover */ | | | ` ` |<-+ | | | ` ` | |6b.HO_CNF_REQ(nCOA2) | ` ` +------------------+------------------+----------------->| ` ` | 6c.HO_CNF_ACK | ` ` |<-------------------------------------------------------+ ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` Fig 3 Sequence Diagram For Cell-Search List Assisted Handover As an example, letÆs assume the following data is provided via the last CSLIST-IND message that triggered the handover: +------+------+------+------+ | AP | oAP | nAP1 | nAP2 | +------+------+------+------+ | SLEV | 34 | 48 | 57 | +------+------+------+------+ R.Jayaraj Expires - November 2002 [Page 7] Internet Draft Cell-Search List For Handover May 2002 Also, assume that the oAR, through the latest resource update it received, has the following resource usage information regarding its neigbours: +------+------+------+------+ | AP | oAR | nAR1 | nAR2 | +------+------+------+------+ | RES | 34 | 24 | 48 | +------+------+------+------+ Base on signal strengths alone, it would seem that nAP2/nAR2 is the best target for handover, followed by nAP1/nAR1. However, minding the resource usage information, letÆs say the HM entity on the oAR determines the following order in terms of target selection: nAP1/nAR1, nAP2/nAR2. c) Based on the order of nARs in this list, the oAR makes an attempt at nAR1 by sending a handover request (HO_REQ) message to it. This message carries QoS and/or security context information (oCtx) associated with the MN and oAR-nAR BET establishment primitives. If nAR1 rejects oCtx, perhaps due to lack of resources, it sends the handover reject message (HO_REJ) to oAR (3). d) On receipt of the rejection from nAR1, oAR proceeds to request a handover with nAR2, which is next in its candidate routers list. nAR2 accepts the handover request by sending the HO_CNF primitive carrying its router advertisement (nRA2), and, if stateful IP autoconfiguration is used, the new IP address (nCOA2) that the MN should use on its new link (4). The oAR then establishes a oAR-nAR2 BET. e) The oAR then sends a handover command to the MN, passing nAP2's tuning parameters (nAP2) and nRA2 and nCOA2, to which the MN responds by tuning to nAP2 and commiting the RA information to its IP stack (5). f) Thenafter, the MN and nAR2 exchanges messages to determine success or failure of the handover (6). The ability of the network to associate APs to ARs reguire that network maintain a list of the identities, channel, frequency and/or hardware addresses and associated subnets and ARs for every AP under its management. In the distributed approach, portions of this list are configured into ARs in the network via network management protocols such that each portion not only contains information on the APs on the subnet R.Jayaraj Expires - November 2002 [Page 8] Internet Draft Cell-Search List For Handover May 2002 which the AR serves, but also on adjacent APs and the ARs on whose subnet they are connected to. 5. Configuring the Cell-Search Threshold and List Indication In the course of initially associating with an AP on a network and registering for access with the network through the EAP, the MN should allow the network to configure the parameters associated with the sending of the cell-search list indications, such as the trigger event to enter the cell-search mode and start sending them, the sending rate and the window averaging operations on the SLEV/SQUA figures to be reported. In this wise, networks that have AP layouts with thick overlapping coverage areas can dictate a higher threshold for cell search and for triggering the cell-search list indications, which will in turn result in a longer time limit to setup the handover, and hence statistically improve the handover success rates. Fig 4 and Fig 5 illustrates this option. The cell-search and list indication configuration message is described in section 7.1. R.Jayaraj Expires - November 2002 [Page 9] Internet Draft Cell-Search List For Handover May 2002 ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `Signal +4 ` ` ^ |+5 ` ` | ||+6 ` ` | MN -------+++-----> MN' ` ` | 3 ||| ` ` | @@@@ ||| #### ` ` | @@@@@@@@ ||| ######## ` ` | @@@@@@@@@@@@ ||| ############ ` ` | @@@@@@@@@@@@@@ ||| ############## ` ` | @@@@@@@@@@@@@@@@ |||################ ` `1+---@@@@@@@@@@@@@@@@@@-|##################----` ` | @@@@@@@@@@@@@@@@@@@@#################### ` `2+-@@@@@@@@@@@@@@@@@@@@@@####################--` ` +-----------+-------------------+------------>` ` oAP 7->||<-7 nAP Distance` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `1 û Cell search start below this level ` `2 - Link is lost below this level ` `3 - Direction of MN's movement ` `4 - MN starts scanning for neighbour APs ` `5 - Handover is triggered by nAP > oAP + hysteresis ` `6 - Handover must complete before this point ` `7 - Maximum handover setup time ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` Fig 4 Anticipative handover can be statistically dicey if APs are not sufficiently overlapped. ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `Signal ` ` ^ ` ` | | | ` ` | @@@@ | #### ` ` | @@@@@@@@ | ######## network-dictated` ` +-------@@@@@@@@@@@@############-------- cell-search ` ` | @@@@@@@@@@@@@@############ threshold ` ` | @@@@@@@@@@@@@@@@############ ` ` | @@@@@@@@@@@@@@@@@@############ ` ` | @@@@@@@@@@@@@@@@@@@@############ link-critical ` ` +--@@@@@@@@@@@@@@@@@@@@@@############--- threshold ` ` +------------+------+---++---------------------------> ` ` oAP ->| |< nAP Distance ` ` maximum handover setup time increased ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` Fig 5 If APs are overlapped sufficiently, letting the network dictate cell-search threshold can improve handover success rate R.Jayaraj Expires - November 2002 [Page 10] Internet Draft Cell-Search List For Handover May 2002 6. The WIF-SAP In order to support the above scheme, the function of handover and AP-reassociation needs to be taken out of the wireless LAN adaptors (considered as Layer-2 in the IP stack), and promoted to the HM entity which is on par with the IP layer. This requires the adaptors to export programming interfaces to provide following functions: a) strict association with an AP by channel, frequency or MAC/ hardware address, such that the adaptor does not change its AP association even when it moves out of the coverage of that AP (AP-ASSOC-CMD). b) configurable cell-search mode that provides periodic measurements of the signal level and/or quality of the serving neighbour APs (CSLIST-IND-L2). c) indication of the completion of the AP re-association procedure (AP_ASSOC_CMPLT_IND), in the case where a) is a non-blocking call. Fig 6 shows the use of these programming interfaces in relation to the handover scenario described in section 4. +---------+ +---------+ | |---1b-->| AR::RM | L3 | MN::HM |---1b-->| /HM | 1a CSLIST-IND-L2 | |<--5a---| | 1b CSLIST-IND | |---6b-->| | 5a HO_CMD +---------+ +---------+ 5b AP_ASSOC_CMD ^ ^ | ^ 6a AP_ASSOC_CMPLT_IND 1 1 5 6 6b HO_CNF_REQ a a b a | | V | RM Resource Management +---------+ HM Handover Management L2/MAC | MN::WIF | WIF Wireless Interface +---------+ Fig 6 Client Adaptor Programming Interfaces On some cards and on the Linux environment, the 'wireless-tools' package can be used to provide workarounds or simulations for a) and b). However, performance will not be as good as if the client adaptor drivers themselves provide these services. R.Jayaraj Expires - November 2002 [Page 11] Internet Draft Cell-Search List For Handover May 2002 7. Suggested Message Structures 7.1 Cell-Search and List Indication Configuration Command This element consists of the following sub-elements: a) Flag. This flag is used to indicate absence or presence of the following elements. b) Cell-Search Threshold. This is a technology-specific element and defines the threshold below which the MN should enter cell- search mode and start measuring the signal level and/or quality of nAPs. c) Measurement Condition Clause. This element dictates when the MN should start sending the CSLIST-IND messages. It consists of the following elements: i) Condition Flag-Pairs. Bits in these flag-pairs denote conditions for which the MN should send the cell-search list indication, e.g. with immediate effect, on serving AP signal level going under -X dBm, on a neighbour AP signal quality going X dBm above the serving AP's, etc. These bits come in pairs to allow 'and/or' conjugate conditions to be specified. ii) Condition Parameters. For each condition specified in i) above, its associated X parameters are specified here. d) Measurement Method Clause. This element dictates the interval at which, and the number of times the cell-search list indications should be sent by the MN on meeting the condition clause. It consists of the following elements: i) Method Flag. Bits in this flag denote methods, e.g. at regular X intervals, function mX + Y of signal level/quality, X number of times, apply X point sampling between indications, and Y window averaging using Z filter, etc. ii) Method Parameters. For each method specified in i) above, its associated X,Y and Z parameters are specified here. 7.2 Cell-Search List Indication (CSLIST-IND) This message consists of the following sub-elements: a) Measurement Flag. Bits in this flag determine if, R.Jayaraj Expires - November 2002 [Page 12] Internet Draft Cell-Search List For Handover May 2002 i) The given measurements are valid/accurate. ii) Signal level is measured. iii) Signal quality is measured. b) Number Of APs. This gives the number of APs for which measurements are included in this message. c) AP Measurements Entries. These contain the actual signal level and/or quality measurements for each AP that the MN measured. The number of entries is given by b) above. Each entry consists of the following elements: i) AP Id. A mutually agreed number between the MN and the network identifying the AP. ii) Channel/Frequency/MAC Address. This may be given in place of i). iii) Signal Level. This is the signal level measurement of the AP. iv) Signal Quality. This is the signal quality of the AP. 7.3 Handover Command (HO-CMD) The handover command message consists of the following sub- elements: a) AP Information. This element indicate to the MN the AP that it should handover to, and it includes: i) AP Id. A mutually agreed number between the MN and the network identifying the AP. ii) AP Tuning Parameters. This may be given in place of i). b) IP address on the new subnet. This element is present if an inter-subnet handover is required, and the network employs stateful IP configuration for MNs. It is the IP address that the MN should use on the new link. c) Router Information. This element is present if an inter-subnet handover is dictated. On IPv6 networks, it is basically the RA from the nAR. R.Jayaraj Expires - November 2002 [Page 13] Internet Draft Cell-Search List For Handover May 2002 8. Security Considerations Over the air interface, all information elements may be sent encrypted using encryption methods made available by the EAP, and using a security context negotiated with the network in the course of registering for access. 9. Scalability Considerations At the subnet level, the mechanism may add additional processing load on ARs, thus lowering the maximum number of MNs that can be attached to the subnet. However, at the network level, operations can be distributed across ARs. In this way, an increase in the number of MNs can be compensated by an increase in the number of subnet/ARs. References [2002] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [MIP6] D. Johnson, et. al. "Mobility Support In IPv6", draft-ietf-mobileip-ipv6-14.txt, Work In Progress, July 2001. [LOWLATENCY] K. El Malki, et. al., "Low Latency Handoff In Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt. Work In Progress, May 2001. [FASTMIP6] G. Tsirtsis, et. al., "Fast Handovers For Mobile IPv6", draft-ietf-mobileip-fast-mpv6-01.txt. Work in progress, April 2001. [CTX] O. H. Levkowetz et. al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", draft-ietf-seamoby-context-transfer-problem-stat-01.doc, Work In Progress, May 2001. [CTXREQ] H. Sayed et. al., "General Requirements for a Context Transfer Framework", draft-ietf-seamoby-ct-reqs-00.txt, Work In Progress, May 2001. R.Jayaraj Expires - November 2002 [Page 14] Internet Draft Cell-Search List For Handover May 2002 [GSMRR] ETSI, ôDigital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 specification; Radio Resource Control Protocol (GSM 04.18 version 8.4.1 Release 1999)ö. 1999. [DHC6] J. Bound et. al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-24.txt, Work In Progress, April 2002. Author's Contact Information Raymond Jayaraj Institute For Communications Research 20 Science Park Road, #02-34/37 Science Park II, Singapore 117674 Phone: +65-68709330 Fax: +65-67745441 Email: jraymond@cwc.nus.edu.sg R.Jayaraj Expires - November 2002 [Page 15]