idnits 2.17.1 draft-ietf-seamoby-cardiscovery-issues-01.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... months and m...' == Line 28 has weird spacing: '... The list of...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 487, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 496, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. '3') -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-context-transfer-problem-stat-01 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '5') == Outdated reference: A later version (-05) exists of draft-ietf-seamoby-ct-reqs-00 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-ct-reqs (ref. '6') -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 1771 (ref. '9') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1591 (ref. '10') ** Obsolete normative reference: RFC 1777 (ref. '11') (Obsoleted by RFC 3494) Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Seamoby Working Group Dirk Trossen 2 INTERNET-DRAFT Govind Krishnamurthi 3 draft-ietf-seamoby-cardiscovery-issues-01.txt Hemant Chaskar 4 20 September 2001 Nokia 5 James Kempf 6 Sun Microsystems, Inc. 8 Issues in candidate access router discovery 9 for seamless IP-level handoffs 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. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet 19 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or made obsolete by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 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 Copyright Notice 33 Copyright (c) The Internet Society (2001). All rights reserved. 35 ABSTRACT 37 Handoff in IP mobility protocols involves moving a mobile node's 38 Layer 3 routing reachability point from one access router to another, 39 before or after the mobile node has established a Layer 2 connection 40 with the radio access point that is covered by the new access router. 41 In addition, other context information about the mobile node's packet 42 session may be transferred from the old access router to the new one, 43 in order to minimize the service disruption during the handoff 44 process. While the exact details of how this is accomplished vary 45 depending on the IP mobility and seamless handoff protocols, one 46 common thread required for seamless handoffs is identifying the 47 candidate access routers for the mobile node's handoff. At the time 48 of IP-level handoff, if a collection of candidates has been 49 identified, an algorithm is run to determine the target access 50 router for the mobile node's handoff. This document presents a 51 problem statement describing issues involved in designing a candidate 52 access router discovery protocol. The document does not discuss the 53 algorithm by which the actual target router is selected, nor how the 54 handoff to the target is achieved. 56 TABLE OF CONTENTS 58 1. INTRODUCTION 1 60 2. MOTIVATION FOR CAR DISCOVERY 1 62 3. TERMINOLOGY 2 64 4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 3 66 4.1 Anticipated CAR Discovery 3 67 4.2 Dynamic CAR Discovery 4 68 4.3 Hybrid CAR Discovery 5 70 5. SPECIFIC ISSUES IN CAR DISCOVERY 5 72 5.1 Identifying GAARs 5 73 5.2 Identifying capabilities of GAARs 7 74 5.3 Security considerations 8 76 6. APPLICABILITY OF EXISTING PROTOCOLS 8 78 7. REFERENCES 9 80 8. AUTHORS' ADDRESS 10 82 ACKNOWLEDGMENTS 84 Special thanks are due to John Loughney (Nokia) for his input 85 during the preparation of this document. 87 1. INTRODUCTION 89 IP mobility protocols enable mobile nodes (MNs) to change the access 90 routers (ARs) by which they obtain the Layer 3 connectivity to 91 the Internet, while communicating with another node over the 92 Internet. An AR providing Internet connectivity to the MN changes 93 when the movement of the MN causes a change in the radio access point 94 through which the MN communicates with the wired network, such that 95 the AR serving the new radio access point is in a new subnet. There 96 are existing solutions [1, 2] that enable MNs to execute IP-level 97 handoffs between the ARs. Additionally, work is underway [3, 4, 5, 98 6, 7], to define protocols that would allow seamless, meaning low 99 latency and low packet loss, handoffs of MNs between the ARs. These 100 handoff solutions assume that the identity (IP address) of the target 101 AR is known to the current AR. They do not provide a solution to the 102 problem of selecting the target AR for the MN's handoff. What is 103 required is a protocol that would allow an AR or an MN to discover 104 the neighboring ARs whose capabilities meet the requirements of 105 a MN, thus becoming potential target ARs for handoff. Such ARs are 106 called "Candidate ARs". This information can be used for selecting 107 the target AR at the time of MN's handoff. This draft discusses the 108 issues involved in the problem of Candidate AR discovery. The draft 109 does not discuss the problem of selecting the target AR to which 110 handoff is performed, nor the handoff process itself. 112 To motivate the Candidate AR discovery problem, we now describe some 113 illustrative scenarios in which the Candidate AR discovery protocol 114 may be useful. 116 2. MOTIVATION FOR CANDIDATE AR DISCOVERY 118 This section describes some seamless handoff features that can be 119 implemented if there are means to identify the Candidate ARs for 120 the MN's handoff. 122 Scenario 1: Load balancing 124 Consider an AR to which an MN is currently attached. This AR is 125 denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose 126 there is another AR, denoted by AR2, that is reachable from the 127 attached MN and is not heavily loaded. If AR2 has the capabilities to 128 satisfy the MN's requirements, AR1 can initiate a handoff of the MN 129 to AR2 to alleviate some of its own load. For this, AR1 needs to have 130 the knowledge of the capabilities of AR2 and the load on AR2. Such an 131 information sharing can be achieved with the help of Candidate AR 132 discovery protocol. 134 Scenario 2: Resource intensive applications 136 Consider an MN running a streaming video application, which might be 137 an important application for the future mobile networks. These 138 applications require high bandwidth and possibly other QoS support to 139 be available at the AR serving the MN. When this MN moves into the 140 coverage area of a new AR, it is possible that the new AR does not 141 have the capability to support the MN's application. The MN can then 142 be informed about this fact when it is still connected to the current 143 AR. Clearly for this, the current AR needs to have information about 144 the capabilities of the neighboring ARs, and this can be achieved 145 using the Candidate AR discovery protocol. 147 Scenario 3: Least-cost phone call 149 Consider the preference expressed by the MN to prioritize handoffs 150 to an AR with minimal cost of access for phone call ('least cost 151 policy'). Due to the real-time nature of the service, seamless 152 handoffs are preferred to minimize service disruption. In addition, 153 the 'cost of access' capability information, if available, is 154 included in the target AR selection process as an MN-specific 155 preference. 157 Scenario 4: Adaptability to change in the coverage topology 159 Consider a situation in which ARs may be temporarily introduced in 160 hot-spots to cater to the existing traffic demand. In such a case, 161 a static configuration of the neighborhood information in ARs is not 162 feasible as the operators may not inform each other of temporary 163 changes. A protocol is therefore needed in such cases so that an AR 164 can automatically identify any change in the coverage topology and 165 exchange capability information with the neighboring ARs. This can 166 be facilitated by the Candidate AR discovery protocol. 168 3. TERMINOLOGY 170 Access Point (AP) 172 A radio transceiver by which an MN obtains Layer 2 connectivity 173 with the wired network. 175 Access Router (AR) 177 An IP router residing in an access network and connected to one 178 or more APs. An AR offers IP connectivity to MN. 180 Geographically Adjacent AR (GAAR) 182 An AR whose coverage area is such that an MN may move from the 183 coverage area of the AR currently serving the MN into the coverage 184 area of this AR. In other words, GAARs have APs whose coverage 185 areas are geographically adjacent or overlap. 187 Capability of AR 189 A characteristic of the service offered by an AR that may be of 190 interest to an MN when the AR is being considered as 191 a handoff candidate. 193 Candidate AR (CAR) 195 This is an AR that is a candidate for MN's handoff. CAR is 196 necessarily a GAAR of the AR currently serving the MN, and also has 197 the capability set required to serve the MN. 199 Target AR (TAR) 201 This is an AR with which the procedures for the MN's IP-level handoff 202 are initiated. TAR is usually selected from the set of CARs. 204 TAR Selection Algorithm 206 The algorithm that determines a unique TAR for MN's handoff from 207 the set of CARs. The exact nature and definition of this algorithm 208 is outside the scope of this document. 210 4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 212 There are two basic approaches to CAR discovery, namely, Anticipated 213 CAR Discovery and Dynamic CAR Discovery. 215 4.1 Anticipated CAR Discovery 217 In this approach, an AR currently serving the MN identifies all CARs 218 for the MN's handoff, at some point prior to handoff. This 219 information is then immediately available at the time of handoff as 220 input to the TAR Selection Algorithm. Another input to the TAR 221 Selection Algorithm may be the preferences expressed by the MN prior 222 to the handoff, or preferences enforced by the administrative 223 control. At the time of handoff, it may only be required to provide 224 input to TAR Selection Algorithm about the reachability of 225 neighboring ARs from the MN. This reachability information is usually 226 in the form of identity of the AP to which the MN can listen to, and 227 the current AR has to resolve this AP identity to the GAAR's IP 228 address. 230 The advantage of this approach is that the handoff can be executed 231 quickly because the AR has already collected much of the information 232 needed by the TAR Selection Algorithm. Also, this approach does not 233 generate much radio traffic for performing CAR discovery as the 234 capability exchange happens over the wired network. 236 The Anticipated CAR Discovery problem encompasses the areas outlined 237 in the box in Figure 1. 239 ----------------------------------------------------------------- 240 | All routers | 241 | | Discovery of ARs whose coverage | 242 | | areas overlap (GAARs)with that of | 243 | v the current AR | 244 | Local map of GAARs at current AR | 245 | | | 246 | | Capability identification | 247 | v | 248 | CARs for MN's handoff identified at current AR | 249 | | | 250 --------------------------|-------------------------------------- 251 | 252 | Predefined preferences of the MN 253 AR Reachability | and administrative preferences 254 for the MN | 255 | | | 256 v v v 257 TAR Selection Algorithm executed at the time of 258 handoff to determine unique TAR for MN's handoff 260 Figure 1: The Anticipated CAR Discovery Problem 262 4.2 Dynamic CAR Discovery 264 In this approach, an MN dynamically obtains information about 265 the available ARs for handoff, along with their capabilities. When 266 the MN detects an AR that has capabilities which match its 267 preferences, the MN may notify the currently serving AR to perform a 268 handoff to this AR using one or more of the seamless handoff 269 protocols. 271 The advantage of this technique is that the MN has fine-grained 272 control over the TAR selection. However, this approach generates more 273 radio traffic during the CAR discovery step. This is because, 274 capability information is sent to the MN over the air. Also, it is 275 required that the MN can receive IP-level capability information from 276 the GAARs and negotiate requirements with the GAARs, while still 277 being connected to the current AR. 279 The Dynamic CAR Discovery problem encompasses the areas outlined 280 in the box in Figure 2. 282 -------------------------------------------------------------- 283 | | 284 | GAARs identified by MN | 285 | | | 286 | | Capability identification by MN | 287 | | | 288 | v | 289 | CARs for MN's handoff identified at MN | 290 | | | 291 ---------------------------|---------------------------------- 292 | 293 | TAR selection by MN at the 294 | time of handoff 295 v 296 Unique TAR identity sent to current AR 298 Figure 2: Dynamic CAR Discovery Problem 300 4.3 Hybrid CAR Discovery 302 In practice, a hybrid of the above techniques for CAR discovery may 303 be used. In the hybrid approach, the partitioning of capability 304 information between the two techniques as well as the partitioning of 305 TAR selection process between the MN and the current AR is possible. 307 5. SPECIFIC ISSUES IN CAR DISCOVERY 309 The following sections describe the specific issues in the CAR 310 discovery, may it be done in anticipated, dynamic or hybrid way. 312 5.1 Identifying GAARs 314 A basic requirement for a new AR to be considered as a CAR for MN's 315 handoff is that the coverage area of the new AR be "geographically" 316 adjacent to or overlapping with that of the AR currently serving the 317 MN. In other words, a new AR must be a GAAR. Note, the geographical 318 vicinity of the coverage areas of two ARs is not necessarily implied 319 by their "logical" adjacency. Logical adjacency of two ARs means that 320 there is just one IP hop between the two ARs, while the adjacency of 321 the coverage areas of two ARs implies that the MN can actually move 322 from the coverage area of one AR to another (GAARs have APs whose 323 coverage areas are adjacent or overlapping). Conversely, GAARs need 324 not be logically adjacent, and may even have IP addresses in 325 different administrative domains. 327 The MIP fast handoff protocols specified in [3] and [4] or the 328 context transfer framework specified in [6] require that the current 329 AR or Foreign Agent (FA) (generically called ARs here for short) have 330 a list of ARs to which a MN could be handed over. In other words, the 331 current AR has a list of CARs. There is no reason, a priori, why 332 these CARs need to in topologically adjacent subnets. A CAR could 333 potentially be in a completely different BGP autonomous system. The 334 only requirement is that the corresponding APs be geographically 335 adjacent. Fig. 3 illustrates the problem. 337 BGP Autonomous BGP Autonomous 338 System A System B 340 +----+ +----+ 341 | BR |---> The Internet <---| BR | 342 +----+ (aka Cyberspace) +----+ 343 / \ 344 / \ 345 +----+ +----+ 346 | IR | | IR | 347 +----+ +----+ 348 | | 349 | | 350 +----+ +----+ 351 | AR | | AR | 352 +----+ +----+ 353 | | 354 |___________________ ________________| 355 | | | | 356 ... | -- -- | ... 357 | \/ \/ | 358 | | 359 |_______ ______| 360 | | | | 361 | -- -- | The Physical World 362 | \/ \/ | (aka Geospace) 363 | | 364 |______ _______| 365 | | 366 -- -- -- 367 \/ = AP \/ \/ 369 Figure 3: GAAR Discovery Problem 371 In the figure, the APs are shown connected to ARs in completely 372 different BGP autonomous systems, but the same problem occurs 373 if the APs are geographically adjacent and the ARs are in subnets 374 that are topologically distant within an autonomous system. The 375 criterion for an AR to be a candidate for an MN's handoff is the 376 geographical adjacency of the AP served by it to that of the AP to 377 which the MN is currently attached, and not the topological adjacency 378 of the corresponding ARs. Hence, IP routing protocols, such as OSPF 379 [8] or BGP [9], are not the solutions to GAAR discovery problem. 381 One approach is to manually configure this geographical neighborhood 382 at each AR. However, such an approach has disadvantages and in many 383 cases, may not be feasible. For instance, the GAARs may be under 384 different administrative control, and thus, are not informed about 385 each other's presence. Even within the same administrative domain, 386 the manual configuration approach demands much network planning in 387 terms of the coverage areas of different ARs. Finally, the manual 388 configuration approach is not suitable if the ARs can be physically 389 relocated or their coverage area changed, thus altering the 390 geographical scope of their coverage areas. Such a scenario is very 391 common when ARs are temporarily introduced in hot spots. Clearly, a 392 more automatic and dynamic mechanism is needed to discover GAARs 393 without much administrative intervention. 395 For the Anticipated CAR Discovery, the process of identifying GAARs 396 requires a protocol that allows ARs to exchange the information about 397 the geographical adjacency of their APs, in advance of handoff. In 398 Dynamic CAR Discovery, the MN automatically serves as the judge of 399 whether an AR is a GAAR. In the latter case, if the MN can hear a 400 Router Advertisement of the new AR, then the new AR is GAAR. 402 5.2 Identifying capabilities of GAARs: 404 Although not common now, the future generation mobile networks may 405 consist of ARs that are GAARs of each other, but are heterogeneous in 406 administrative control, functionality, link layer technology and 407 resources. An MN that is attached to a given AR may have specific 408 requirements as regards these parameters. For example, the MN may 409 need some hardware or software support from the AR or need some 410 application servers topologically close to the AR, to run certain 411 IP-based applications. Support for QoS, security, multicast, header 412 compression etc. are some other aspects that need to be considered 413 when choosing the CAR for MN's handoff. It may also be required to 414 assure some security association, policy agreement or billing 415 contract between the current AR and its GAARs in order to allow 416 MN's handoff between them. Finally, the access routers that are GAARs 417 of each other need to exchange information regarding the 418 correspondence between their IP addresses and the identities of the 419 APs (which the MN can listen to) that are connected to them. 421 In the Anticipated CAR Discovery, capability exchange between ARs 422 occurs over the Internet. Thus, a protocol is needed that would allow 423 ARs to exchange capability information. Capability exchange between 424 ARs should also allow periodic as well as "as needed" exchange of 425 capabilities between GAARs. 427 In the Dynamic CAR Discovery approach, the MN is soliciting or 428 receiving the capabilities of GAARs directly. Some protocol is 429 required to allow the MN to solicit, or the ARs to advertise their 430 capabilities. 432 5.3 Security considerations 434 CAR discovery may allow other nodes to learn the following pieces of 435 information about an AR: 437 - Physical location 438 - Capabilities 439 - State of capabilities. 441 Malicious nodes may use this kind of information to launch attacks of 442 the DoS-style and/or service hijacking. Therefore, the following 443 topics should be covered in any protocol developed for CAR discovery: 445 - Authentication of nodes 446 - Security associations between nodes 447 - Message/payload encryption. 449 6. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM 451 The simplest possible discovery solution is to statically configure 452 the ARs in two geographically adjacent domains with the IP addresses 453 of their counterparts in the other domain. This solution is 454 impractical, particularly when the geographically adjacent domain 455 belongs to another administrative entity, such as a different 456 Wireless ISP (WISP). The neighboring WISP may decide to reconfigure, 457 add subnets, or remove them, as traffic patterns change. Propagating 458 those changes into static configurations would result in significant 459 availability lags. 461 Another solution is to use a simple directory based discovery 462 solution, such as DNS [10], LDAP [11], or SLP [12]. Attribute-based 463 discovery mechanisms such as LDAP and SLP could potentially handle 464 non-geographic capabilities, such as radio technology, but geographic 465 information may be difficult to cast into the form of attribute/value 466 pairs. In addition, information on changes in AR availability needs 467 to propagate dynamically between ARs rather than requiring the ARs to 468 explicitly ask for it. Finally, the client-server nature of these 469 protocols has the associated scalability and robustness concerns. 471 7. REFERENCES 473 [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. 475 [2] Mobility Support in IPv6, D. Johnson and C. Perkins, 476 draft-ietf-mobileip-ipv6-13.txt, 477 work in progress, November 2000. 479 [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 480 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 481 work in progress, February 2001. 483 [4] Fast handoffs for Mobile IPv6, MIPv6 handoff Design Team, 484 draft-ietf-mobileip-fast-mipv6-01.txt, 485 work in progress, April 2001. 487 [5] Problem Description: Reasons For Performing Context Transfers 488 Between Nodes in an IP Access Network, O. H. Levkowetz et. al., 489 draft-ietf-seamoby-context-transfer-problem-stat-01.doc, 490 work in progress, May 2001. 492 [6] General requirements for a context transfer framework, H. Sayed 493 et. al., draft-ietf-seamoby-ct-reqs-00.txt, 494 work in progress, May 2001. 496 [7] Buffer Management for Smooth handoffs in Mobile IPv6, 497 G. Krishnamurthi, R. Chalmers, and C. Perkins, 498 draft-krishnamurthi-mobileip-buffer6-01.txt, 499 work in progress, March 2001. 501 [8] Open Shortest Path First protocol, Version 2, J. Moy, RFC 2328, 502 April 1998. 504 [9] A Border Gateway Protocol 4 (BGP-4), edited by Y. Rekhter and 505 T. LI, RFC 1771, March 1995. 507 [10] Domain Name System Structure and Delegation, J. Postel, RFC 1591, 508 March 1994. 510 [11] Lightweight Directory Access Protocol, W. Yeong, T. Howes, and 511 S. Kille, RFC 1777, March 1995. 513 [12] Service Location Protocol, Version 2, E. Guttman et. al., 514 RFC 2608, June 1999. 516 8. AUTHORS' ADDRESS 518 Dirk Trossen 519 Communication Systems Laboratory 520 Nokia Research Center 521 5 Wayside Road 522 Burlington, MA 01803, USA 524 Phone: +1 781 993 3605 525 Fax: +1 781 993 1907 526 E-mail: dirk.trossen@nokia.com 528 Govind Krishnamurthi 529 Communication Systems Laboratory 530 Nokia Research Center 531 5 Wayside Road 532 Burlington, MA 01803, USA 534 Phone: +1 781 993 3627 535 Fax: +1 781 993 1907 536 E-mail: govind.krishnamurthi@nokia.com 538 Hemant Chaskar 539 Communication Systems Laboratory 540 Nokia Research Center 541 5 Wayside Road 542 Burlington, MA 01803, USA 544 Phone: +1 781 993 3785 545 Fax: +1 781 993 1907 546 E-mail: hemant.chaskar@nokia.com 548 James Kempf 549 Network and Security Research Center, Sun Labs 550 Sun Microsystems, Inc. 551 15 Network Circle 552 Menlo Park, CA 94025, USA 554 Phone: +1 650 786 5890 555 Fax: +1 650 786 6445 556 E-mail: james.kempf@eng.sun.com