idnits 2.17.1 draft-elmalki-mobileip-fast-handoffs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 369 has weird spacing: '...lishing new ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1999) is 8990 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-00 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT K. El Malki, N. A. Fikouras 2 University of Sheffield 3 4th March 1999 4 Expires September 1999 6 Fast Handoff Method for Real-Time Traffic over 7 Scaleable Mobile IP Networks 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. Internet-Drafts 15 are working documents of the Internet Engineering Task Force 16 (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines the operations to be performed by 34 scaleable Mobile IP [1] networks during handoffs in order to 35 support real-time traffic which has delay bounds. This method is 36 based on the Regionalized Tunnel Management [2] approach. A 37 method is described in this document which defines the operation 38 of Mobile Nodes, Foreign Agents and Hierarchical Proxy Foreign 39 Agents. This utilises multiple bindings in order to "multicast" 40 traffic to potential Mobile Node movement locations in order to 41 anticipate movement. This eliminates the service disruption 42 period which is currently present during handoffs in Mobile IP 43 networks due to registration delay. The information redundancy 44 lasts only for very short periods and the waste of bandwidth is 45 therefore minimal. 47 Table of Contents 49 1.0 Introduction 50 1.1 Assumptions 51 1.2 Acronyms 52 2.0 Description of the Fast Handoff Method 53 2.1 Overall Method and Architecture 54 2.2 Mobile Node (MN) functionality for Fast Handoffs 55 2.3 Foreign Agent (FA), Proxy Foreign Agent (PFA) and Top- 56 level Proxy Foreign Agent (TPFA) functionality for 57 Fast Handoffs 58 2.4 Support of "forward" and "backward" MN movement 59 2.5 Fast Handoffs applied to multiple BSs having 60 common wireless overlap regions. 61 3.0 Security Considerations 62 4.0 References 63 5.0 Author's Address 65 1. Introduction 67 Mobile Nodes (MNs) will vary their point of attachment to the 68 Internet frequently. MNs which move in this way suffer a period 69 of communication breakdown due to the time needed to update the 70 MNs' location information (i.e. registration with the Home 71 Agent). During these periods MNs experience a service disruption 72 which undermines the quality of real-time services. 74 In this document a Fast Handoff method is described. This method 75 eliminates the service disruption period due to handoffs by 76 anticipating the MN's movement and using multiple bindings to 77 direct the MN's traffic to the multiple locations which it may 78 move to. 80 Although some waste of bandwidth will occur, this is minor since 81 it will only last for the very short period in which a MN lies 82 in the wireless overlap region of two network access points. We 83 identify the movement between two access points as comprising 84 both a movement between BSs (Base Stations: layer 2 mobility) 85 and a movement between Mobility Agents (MAs). This method does 86 not rely on the assumption of single-MA networks, and is 87 applicable to multiple-MA networks. Finally, the Fast Handoff 88 method may be applied to scenarios in which a Mobile Node enters 89 the wireless overlap region of multiple BSs, and not only two as 90 considered above. 92 1.1 Assumptions 94 This method makes use of hierarchical agents and the 95 Hierarchical Mobility Agent Extension [2]. It is also assumed 96 that a FA will send advertisements containing its address and 97 the addresses of all other PFAs in its hierarchical branch of 98 the network using the PFA IP address extension [2]. These will 99 be advertised in hierarchical order and this order cannot be 100 modified. 102 This method also assumes an underlying layer 2 protocol which 103 allows a mobile node to receive and transmit contemporarily 104 from/to multiple Base Stations (BSs) when in their wireless 105 overlap region. A particular pattern of MN movement is not 106 assumed, hence this method will provide seamless (loss-less) 107 service to MNs moving "forward" and "backward" into any number 108 of location and overlap regions. 110 No limit is assumed regarding the number of MA levels in a 111 hierarchy. 113 1.2 Acronyms 115 MN Mobile Node 116 FA Foreign Agent 117 HA Home Agent 118 PFA Proxy Foreign Agent 119 TPFA Top-level Proxy Foreign Agent 120 MA Mobility Agent. As such are described FAs, HAs, PFAs 121 and TFAs. 122 ISP Internet Service Provider 123 COA Care-of address 124 PM Prefix Matching 125 ECS Eager Cell Switching 126 LCS Lazy Cell Switching 127 NAI Network Access Identifier 129 2.0 Description of Fast Handoffs Mechanism 131 The Fast Handoff mechanism allows efficient handoffs for MNs. It 132 supports Local, Metropolitan and Wide-Area mobility. This method 133 is of greatest efficiency using Local and Metropolitan mobility, 134 which are the most frequent scenarios for a MN. Security is 135 considered in this method. 137 2.1 Overall Method and Architecture 139 .................................................... 140 . . 141 . GLOBAL INTERNET . 142 .................................................... 143 / \ 144 / \ 145 +-------------------------+ +-------------------+ 146 | ISP | | ISP | 147 | ----- | | ----- | 148 Top +---------|TPFA1|---------+ +-------|TPFA2|-----+ 149 Level ----- ----- 150 / \ | 151 ----- \ | 152 Local | PFA | \_______ | 153 ----- \______ \ | 154 / \ \ \ | 155 Lowest ----- ----- ----- ----- ----- 156 Level | FA1 | | FA2 | | FA3 | | FA4 | | FA5 | 157 ----- ----- ----- ----- ----- 158 | | | | | 159 | ---------- | | 160 | | | | 161 BS BS BS BS 162 | | | | 163 MN -------> MN ------> MN ----------> MN 165 1 1ov2 2 2ov3 3 3ov4 4 167 Figure 1: Fast Handoff Network Topology 169 Key: xovy = overlap area between the BSs in Pos. x and y 171 The above diagram illustrates a general network architecture in 172 which ISPs connect users through the Internet. Both single-agent 173 and multiple-agent subnetworks are considered. In this scenario 174 each ISP will host a Top-level MA or a Top-level Proxy Foreign 175 Agent (TPFA). The function of a TPFA is to dynamically manage 176 regional tunnels. Private networks (i.e. company networks) may 177 have their own PFAs if they wish to manage tunnels locally. 178 TPFAs and PFAs can provide fast handoffs by establishing 179 multiple bindings (registrations) for moving MNs. The lowest 180 levels of the MA hierarchy are occupied by FAs which provide 181 network access to MNs. Although figure 1 presents only one level 182 of FAs, any number of FA levels may exist below a given PFA. 183 Furthermore, it is noted that FAs 1, 4 and 5 represent 184 subnetworks with a single FA (i.e. single-agent subnetworks) 185 while FAs 2 and 3 exist within the same subnetwork (i.e. 186 multiple-agent subnetworks). This configuration is typical of 187 private organisations where multiple departments (each having a 188 FA) are located within the same division or building floor and 189 thus share communication resources. It is assumed in figure 1 190 that the MN has a HA connected to a PHA which is located 191 anywhere on the Internet (as in [2]), but is not presented for 192 simplicity. 194 Link layer connectivity is provided by the BSs. Each BS can 195 service MNs within its area of coverage. The overlap of multiple 196 areas of coverage forms an overlap region. These regions are 197 labelled as xovy, identifying the overlap between the two 198 positions (i.e. x and y). It is assumed that a wireless 199 technology is available at Layer 2 which allows the MN to 200 communicate with N BSs when in the overlap region of their 201 coverage areas. 203 All FAs are required to include in their advertisements the PFA 204 IP address extension [2] which will list all PFA's and TPFA's in 205 the same hierarchical "branch" in descending order. Thus, in 206 figure 1 the TPFA is listed first in FA advertisements. MNs are 207 required to cache these lists in order to determine common 208 routes as they move. 210 Generally the TPFA is the single point of access to the Internet 211 for a hierarchy of PFAs. In Figure 1 a scenario is depicted 212 where a PFA denotes a local private or public administrative 213 domain. The PFA can identify an organisational/residential 214 network or it can provide network access to MNs on the street, 215 although this can be done by the TPFA as shown in Figure 1. 217 The following types of mobility are considered: 219 1)Local Mobilty (movements between Pos. 1 to Pos. 2) and 220 Metropolitan-Area mobility (movement between Pos. 2 and Pos. 3) 221 2)Wide-Area Mobility (movement between Pos. 3 to Pos. 4) 223 2.2 Mobile Node (MN) functionality for Fast Handoffs 225 The handoff mechanism is described in this section. Below is a 226 flowchart specifying the MN operations when performing a Fast 227 Handoff. As mentioned previously, TPFAs and PFAs are capable of 228 supporting multiple simultaneous bindings for a MN. 230 It is assumed that the MN, upon movement from the Home network 231 to a Foreign network, will cache the TPFA/PFA address hierarchy 232 from the PFA IP address extension [2] present in FA agent 233 advertisements. In the case of FA1 the extension would include 234 the Local PFA and TPFA1. 236 Some FAs may choose to advertise only Local PFAs. For example, 237 an organisation comprising the Local PFA, FA1, FA2 and FA3 may 238 not want to advertise the TPFA or any other higher PFAs which 239 may exist in between. However this will prevent users from 240 performing seamless handoffs between the organisation's network 241 and the rest of the Internet. That is, fast and seamless 242 handoffs would not be available for movement from position 2 to 243 3 or 2 to 4. 245 In figure 1 it is assumed that the MN has powered up in position 246 1. Having no prior record of a hierarchy it operates as per [2] 247 and issues a Registration Request using as COA (Care-of-address) 248 the IP address of the TPFA. It is assumed that this Request 249 updates the HA's MN location information, that the MN is granted 250 network access and that the MN caches the list of PFAs (CURRENT 251 PFA list) received in the FA agent advertisement. The MA 252 activity in response to the Request is presented in section 2.3. 254 It is assumed that MNs keep record of all the FAs from which 255 they have received an agent advertisement ("known" Agents) even 256 if they belong to different subnetworks. Similarly, the MN keeps 257 record of "known" subnetworks. These are subnetworks in which 258 "known" Agents lie. Furthermore, MNs are required to keep record 259 of all established bindings. Optionally the MN may keep record 260 of PFA IP address lists. 262 Even though all "known" FAs hold the same status, only one FA is 263 the "primary" FA. The binding associated with that FA is always 264 updated by requesting a long lifetime and the PFA list 265 associated with the "primary" FA is considered as CURRENT. 266 Bindings associated with all the FAs, except for the "primary" 267 FA, are updated by requesting a short lifetime (3 * 268 advertisement rate). In this way the method is able to 269 distinguish between the primary traffic flow and auxiliary 270 traffic flows. The purpose of auxiliary flows is to anticipate 271 MN movement into a new subnetwork. In Figure 1, when the MN 272 moves from Position 1 to 1ov2, FA1 will be the "primary" FA 273 while FA2 will receive and provide the MN with the auxiliary 274 traffic flow. 276 "Known" FAs whose lifetime has expired are removed, and so is 277 all cached information associated with them (i.e. bindings, 278 entries in "known" subnetwork list and PFA IP address lists). 279 Using the list of "known" agents and subnetworks, in conjunction 280 with PM (Prefix Matching) and the NAI (Network Access 281 Identifier), can help detect MN movement into new subnetworks. 283 Since a MN may maintain simultaneous bindings with MAs, this 284 method assumes a hybrid LCS-ECS movement detection method with 285 PM or NAI support. That is, MNs are Eager to request 286 simultaneous bindings when movement is detected by PM or NAI 287 domain comparison, but are Lazy to abandon established bindings. 288 This behaviour has been integrated in the flowchart presented 289 below. 291 The following flowchart illustrates the Fast Handoffs procedure 292 for MNs when moving between FAs: 294 .-----------> .-> Has the lifetime of a "known" FA expired ? .NO 295 | | | | 296 | | |YES | 297 | | | | 298 | | Remove FA from the "known" FAs list. | 299 | | De-cache associated PFA list. | 300 | | Delete all associated bindings. | 301 | | (MN is Lazy to abandon bindings) | 302 | | | | 303 | | | | 304 | | | | 305 | | Has the "primary" FA expired ? ------------>| 306 | | | NO | 307 | | |YES | 308 | | | | 309 | | Use FA with longest outstanding lifetime | 310 | | as "primary" FA. | 311 /|\ /|\ Get a new CURRENT PFA IP address | 312 | | extension list. | 313 | | | | 314 | | | | 315 | | | | 316 | | Received any successful Registration <-----. 317 | | Replies ? ---------------------->. 318 | | | NO | 319 | | |YES | 320 | | | | 321 | | Cache associated binding and | 322 | | optionally PFA IP address list. | 323 | | Add FA to "known" FAs list. | 324 | | Add FA's subnet to "known" subnetworks list. | 325 | | | | 326 | | | | 327 | | | | 328 | | Are there any bindings about <---------. 329 | | to timeout ? ----------->. 330 | | | NO | 331 /|\ /|\ |YES | 332 | | | | 333 | | Update bindings by sending a | 334 | | Registration Request with the | 335 | | IP address of the corresponding PFA | 336 | | or TPFA as the COA. | 337 | | Do not set the S bit ON. | 338 | | | | 339 | | | | 340 | |<-- Received new FA Advertisements ? <-------. 341 | | NO (not a "known" FA) 342 | | | 343 | | |YES 344 | | | 345 | | Does PM or NAI comparison indicate 346 | .<---- discovery of a new subnet ? 347 | NO | 348 | |YES 349 | | 350 | Movement has been detected. 351 | Cache PFA IP address extension 352 | list (NEW PFA list). 353 /|\ | 354 | | 355 | Find Common PFA by comparing 356 | CURRENT and NEW PFA lists. 357 | | 358 | | 359 | Is there a Common PFA ? 360 | / \ 361 | YES / \ NO 362 | / \ 363 | Send a Registration Request Send a Registration Request 364 | using the Common PFA as COA using the TPFA as COA. Set the 365 | Set the S bit ON to request a S bit ON to request a simultaneous 366 | simultaneous binding. Use a binding. Use a short lifetime 367 | short lifetime (i.e. (i.e. 3 * advertisement rate). 368 | 3 * advertisement rate). The MN is Eager in establishing 369 | The MN is Eager in establishing new bindings. 370 | new bindings. 371 | | | 372 | | | 373 | | | 374 | \|/ \|/ 375 .<------------------------------------------. 377 When the MN moves into the overlapping region of multiple 378 subnetworks, it will receive agent advertisements containing the 379 PFA IP address extension lists. The MN will therefore be in the 380 position to determine if there is a Common PFA which could 381 potentially send traffic for the MN to both its old and new 382 location. If PM or NAI indicate movement into a new subnetwork 383 then the MN will send a Registration Request. 385 If there is a Common PFA the MN sends a Registration Request 386 with the Common PFA as COA (N.B. the TPFA could be the Common 387 PFA). Otherwise, if there is no Common PFA, the MN will use the 388 TPFA as the COA. The S bit is set ON only when a Common PFA is 389 found, such that the Common PFA maintains simultaneous bindings 390 with the MN. In this case the Common PFA will "multicast" 391 traffic to both MN's registered locations. 393 When the "primary" FA changes, a new Registration Request is 394 issued without setting the S bit. This causes the Common 395 PFA/TPFA to replace the simultaneous bindings held previously 396 with a single binding for the MN's current location. 398 2.3 Foreign Agent (FA), Proxy Foreign Agent (PFA) and Top-level 399 Proxy Foreign Agent (TPFA) functionality for Fast Handoffs 401 Upon receipt of a Registration Request, the FA will add the 402 Hierarchical Mobility Extension. The FA will add its own address 403 to this extension. The FA is aware of the next higher PFA which 404 it already includes in its advertisements. It will therefore 405 send the packet to the next higher PFA. Intermediate FA levels 406 act as simple routers and relay the Request. 408 Each PFA will check whether its address corresponds to the COA. 409 If they do not correspond then the PFA adds its address to the 410 hierarchical agent extension list (hence forming the PFA IP 411 address extension list) and sends the Request onto the next 412 higher PFA which is known and included in all MA advertisements. 414 However, if the PFA's address corresponds to the Request's COA 415 then the PFA will authenticate the MN and terminate the Request. 416 If the Request has the S-bit set then the PFA will add a 417 simultaneous binding for the MN using the next lower level PFA 418 (or FA) as destination. If the S bit is not set then it will 419 replace the old binding it had for the MN with a new one using 420 the next lower level PFA (or FA) as destination. 422 If the Request reaches the TPFA, and the TPFA is not the COA, 423 then the TPFA relays the registration to the PHA. However, if 424 the TPFA is the COA then it acts as a regular PFA. 426 Registration Requests that are accepted produce a Registration 427 Reply. All Registration Replies contain the PFA IP address 428 extension list (Hierarchical Mobility Agent extension). This is 429 the same extension received in the Request, but inverted. It is 430 always relayed to the next lower level PFA. Its address is known 431 since it is present at the top of the PFA IP address list of the 432 Registration Reply. 434 Upon receiving a Registration Reply the PFAs will check if their 435 address is contained in the PFA IP address extension list. If so 436 the PFA will add a binding for the MN using the next PFA (or FA) 437 address in the list as destination. It will then send the Reply 438 to the next lower PFA (or FA) by using the next PFA IP address 439 in the list. 441 In this way every TPFA/PFA in the hierarchy branch will create a 442 binding for the MN with a PFA below in the hierarchy. The 443 advantage of this approach is that when the MN traffic flow has 444 to change part of its route as a result of MN movement then this 445 will affect only certain TPFA/PFAs and not every MA in the 446 branch. The disadvantage of this approach is that every TPFA/PFA 447 is the tunnel endpoint for a MA above itself in the hierarchy 448 but also a tunnel startpoint for a MA below in the hierarchy. As 449 the process of detunneling and tunneling can prove very 450 demanding it is proposed that MAs will in this case avoid 451 detunneling. Instead it is preferred that the MA only change the 452 appropriate fields in the outer (encapsulation) header of 453 incoming encapsulated traffic. "Multicasting" can occur by 454 cloning that same encapsulated traffic. 456 The TPFA or PFA will authenticate the MN upon receiving its 457 Registration Request. If the Request cannot be authenticated 458 then the TPFA or PFA will issue a Registration Reply with a code 459 of 67 (MN failed authentication). (see 3.0) 461 2.4 Support of "forward" and "backward" MN movement 463 This method does not assume that the MN will only move "forward" 464 to a new network. The MN may move into the overlap region of 465 networks and then move back to its original position. Consider 466 the following MN movement: 468 Pos.1 --> Pos. 1ov2 --> Pos.1 469 When the MN moves to Pos. 1ov2, the Fast Handoff method will 470 cause the Local PFA to "multicast" traffic for the MN to both 471 FA1 and FA2. This is done by establishing a new auxiliary route 472 (simultaneous binding) between the Local PFA and FA2. This has a 473 short lifetime and will be renewed as long as the MN stays in 474 Pos. 1ov2. However, when the MN moves back to Pos. 1 the 475 lifetime of the binding between the Local PFA and FA2 will 476 elapse and the "multicasting" will stop. 478 The Fast Handoff method is therefore independent of particular 479 MN movement patterns. 481 2.5 Fast Handoffs applied to multiple subnetworks having a wireless 482 overlap region. 484 Let us consider a situation in which the MN lies in the overlap 485 region of multiple subnetworks. Moreover, let us assume that at 486 least one of the subnetworks consists of multiple advertising 487 MAs. Depending on the protocol that communicates PFA IP 488 addresses to all the MAs in the hierarchy and determines its 489 structure, it is possible that even MAs in the same subnet might 490 advertise different PFA IP address extension lists. 492 Normal ECS [3] operation would force the MN to request a binding 493 for every newly discovered MA. In the case presented this might 494 cause traffic "multicasting" at multiple PFAs in the hierarchy. 495 For this reason the presented method requires a "known" 496 subnetworks list and the use of PM [3] or NAI to distinguish 497 between advertisements coming in from known and unknown 498 subnetworks. Unknown subnetworks are only the ones for which a 499 MN should request a new binding. 501 In the described method this functionality is provided by 502 keeping a list of "known" FAs and subnetworks and using either 503 PM or NAI (tenth step in the flowchart). Thus, as the MN enters 504 a new multiple-agent subnetwork it will only request an 505 additional binding for the first encountered MA. 507 3.0 Security Considerations 509 It is assumed that there is a secure association between the 510 PFAs (including the TPFA) and all the FAs in its hierarchy, in 511 order to prevent intruders from impersonating as PFAs. Moreover, 512 a secure association between the TPFA and the HA or PHA as in 513 [2] is assumed. 515 Potentially a MN can be authenticated by multiple PFAs/TPFA in a 516 hierarchy. A Registration Request that is positively 517 authenticated will result in a positive Registration Reply. As 518 the Reply is being relayed through all the PFAs in the hierarchy 519 new bindings are created and the MN authentication is recorded 520 for future reference. This means that in the future, when a PFA 521 receives a Registration Request with its IP address as COA it 522 may authenticate it and issue a Reply. Otherwise, if the Request 523 cannot be authenticated, a Reply with code 67 (MN failed 524 authentication) is issued. 526 On receipt of a positive Registration Reply, the FA which hosts 527 the MN may grant it with network access. If this Reply is not 528 received or is negative the FA will block network access to the 529 MN (this case is considered by RFC 2002). 531 It is assumed that encryption will exist on the wireless medium 532 at the link-layer. This will stop intruders from intercepting 533 data on the wireless segments. 535 4.0 References 537 [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 538 1996. 539 [2] P. R. Calhoun, G. Montenegro, C.E. Perkins, "Mobile IP 540 Regionalized Tunnel Management", Internet draft (work in progress), 541 draft-ietf-mobileip-reg-tunnel-00.txt, November 1998. 542 [3] C.E. Perkins, "Mobile IP", Addison-Wesley, ISBN 0-201-63469-4, 543 1998. 545 5.0 Author's Address 547 Any query may be directed to: 549 Karim El Malki Nicholas A. Fikouras 550 Dept. of Computer Science Dept. of Computer Science 551 The University of Sheffield The University of Sheffield 552 211 Portobello Street 211 Portobello Street 553 Sheffield S1 4DP, U.K. Sheffield S1 4DP, U.K. 555 Phone: +44-114-2221935 Phone: +44-114-2221873 556 Fax: +44-114-2221810 Fax: +44-114-2221810 557 E-Mail: karim@dcs.shef.ac.uk E-Mail: nick@dcs.shef.ac.uk