idnits 2.17.1 draft-ietf-seamoby-cardiscovery-issues-02.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 494, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 503, 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-02.txt Hemant Chaskar 4 15 January 2002 Nokia 5 James Kempf 6 DoCoMo 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. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY 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 75 6. SECURITY CONSIDERATIONS 8 77 7. APPLICABILITY OF EXISTING PROTOCOLS 8 79 8. ACKNOWLEDGEMENTS 8 81 9. REFERENCES 9 83 10. AUTHORS' ADDRESS 10 85 1. INTRODUCTION 87 IP mobility protocols enable mobile nodes (MNs) to change the access 88 routers (ARs) by which they obtain the Layer 3 connectivity to 89 the Internet, while communicating with another node over the 90 Internet. An AR providing Internet connectivity to the MN changes 91 when the movement of the MN causes a change in the radio access point 92 through which the MN communicates with the wired network, such that 93 the AR serving the new radio access point is in a new subnet. There 94 are existing solutions [1, 2] that enable MNs to execute IP-level 95 handoffs between the ARs. Additionally, work is underway [3, 4, 5, 96 6, 7], to define protocols that would allow seamless, meaning low 97 latency and low packet loss, handoffs of MNs between the ARs. These 98 handoff solutions assume that the identity (IP address) of the target 99 AR is known to the current AR. They do not provide a solution to the 100 problem of selecting the target AR for the MN's handoff. What is 101 required is a protocol that would allow an AR or an MN to discover 102 the neighboring ARs whose capabilities meet the requirements of 103 a MN, thus becoming potential target ARs for handoff. Such ARs are 104 called "Candidate ARs". This information can be used for selecting 105 the target AR at the time of MN's handoff. This draft discusses the 106 issues involved in the problem of Candidate AR discovery. The draft 107 does not discuss the problem of selecting the target AR to which 108 handoff is performed, nor the handoff process itself. 110 To provide motivation for the Candidate AR discovery work, some 111 illustrative scenarios are given below in which Candidate AR 112 discovery protocol will be useful. 114 2. MOTIVATION FOR CANDIDATE AR DISCOVERY 116 This section describes some seamless handoff features that can be 117 implemented if there are means to identify the Candidate ARs for 118 the MN's handoff. 120 Scenario 1: Load balancing 122 Consider an AR to which an MN is currently attached. This AR is 123 denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose 124 there is another AR, denoted by AR2, that is reachable from the 125 attached MN and is not heavily loaded. If AR2 has the capabilities to 126 satisfy the MN's requirements, AR1 can initiate a handoff of the MN 127 to AR2 to alleviate some of its own load. For this, AR1 needs to have 128 the knowledge of the capabilities of AR2 and the load on AR2. Such an 129 information sharing can be achieved with the help of Candidate AR 130 discovery protocol. 132 Scenario 2: Resource intensive applications 134 Consider an MN running a streaming video application, which might be 135 an important application for the future mobile networks. These 136 applications require high bandwidth and possibly other QoS support to 137 be available at the AR serving the MN. When this MN moves into the 138 coverage area of a new AR, it is possible that the new AR does not 139 have the capability to support the MN's application. The MN can then 140 be informed about this fact when it is still connected to the current 141 AR. Clearly for this, the current AR needs to have information about 142 the capabilities of the neighboring ARs, and this can be achieved 143 using the Candidate AR discovery protocol. 145 Scenario 3: Least-cost phone call 147 Consider the preference expressed by the MN to prioritize handoffs 148 to an AR with minimal cost of access for phone call ('least cost 149 policy'). Due to the real-time nature of the service, seamless 150 handoffs are preferred to minimize service disruption. In addition, 151 the 'cost of access' capability information, if available, is 152 included in the target AR selection process as an MN-specific 153 preference. 155 Scenario 4: Adaptability to change in the coverage topology 157 Consider a situation in which ARs may be temporarily introduced in 158 hot-spots to cater to the existing traffic demand. In such a case, 159 a static configuration of the neighborhood information in ARs is not 160 feasible as the operators may not inform each other of temporary 161 changes. A protocol is therefore needed in such cases so that an AR 162 can automatically identify any change in the coverage topology and 163 exchange capability information with the neighboring ARs. This can 164 be facilitated by the Candidate AR discovery protocol. 166 3. TERMINOLOGY 168 Access Point (AP) 170 A radio transceiver by which an MN obtains Layer 2 connectivity 171 with the wired network. 173 Access Router (AR) 175 An IP router residing in an access network and connected to one 176 or more APs. An AR offers IP connectivity to MN. 178 Geographically Adjacent AR (GAAR) 180 An AR whose coverage area is such that an MN may move from the 181 coverage area of the AR currently serving the MN into the coverage 182 area of this AR. In other words, GAARs have APs whose coverage 183 areas are geographically adjacent or overlap. 185 Capability of AR 187 A characteristic of the service offered by an AR that may be of 188 interest to an MN when the AR is being considered as 189 a handoff candidate. 191 Candidate AR (CAR) 193 This is an AR that is a candidate for MN's handoff. CAR is 194 necessarily a GAAR of the AR currently serving the MN, and also has 195 the capability set required to serve the MN. 197 Target AR (TAR) 199 This is an AR with which the procedures for the MN's IP-level 200 handoff are initiated. TAR is usually selected from the set 201 of CARs. 203 TAR Selection Algorithm 205 The algorithm that determines a unique TAR for MN's handoff from 206 the set of CARs. The exact nature and definition of this algorithm 207 is outside the scope of this document. 209 4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY 211 In this section, we describe three approaches to CAR discovery, 212 namely the Anticipated CAR Discovery (discovery prior to handoff), 213 Dynamic CAR Discovery (discovery at the time of handoff) and Hybrid 214 CAR Discovery. 216 4.1 Anticipated CAR Discovery 218 In Anticipated CAR Discovery, CAR discovery is performed at some 219 point prior to the MN performing a handoff. This can be performed in 220 a number of ways and with various entities participating in the 221 process. One illustrative method for Anticipated CAR Discovery is 222 given below. 224 In this method, an AR currently serving an MN can identify a set of 225 CARs for the MN's handoff, at some point prior to handoff. This 226 information is then available at the time of handoff as input to the 227 TAR Selection Algorithm. Another input to the TAR Selection Algorithm 228 may be the preferences expressed by the MN prior to the handoff, or 229 preferences enforced by the administrative control. At the time of 230 handoff, it may only be required to provide input to the TAR 231 Selection Algorithm about the reachability of neighboring ARs from 232 the MN. This reachability information is usually in the form of the 233 identity of the AP to which the MN can listen to, and the current AR 234 has to resolve this AP identity to the GAAR's IP address. 236 The advantage of Anticipated CAR Discovery is that the handoff can be 237 executed quickly because much of the information needed by the TAR 238 Selection Algorithm is collected in advance of handoff. 240 Anticipated CAR Discovery is depicted in Figure 1. 242 ----------------------------------------------------------------- 243 | All routers | 244 | | Discovery of ARs whose coverage | 245 | | areas overlap (GAARs) with that of | 246 | v the current AR | 247 | Local map of GAARs at current AR | 248 | | | 249 | | Capability identification | 250 | v | 251 | CARs for MN's handoff identified at current AR | 252 | | | 253 --------------------------|-------------------------------------- 254 | 255 | Predefined preferences of the MN 256 AR Reachability | and administrative preferences 257 for the MN | 258 | | | 259 v v v 260 TAR Selection Algorithm executed at the time of 261 handoff to determine unique TAR for MN's handoff 263 Figure 1: Anticipated CAR Discovery 265 4.2 Dynamic CAR Discovery 267 In Dynamic CAR discovery, CAR discovery is performed at the time the 268 MN is about to undergo handoff. Again, this can be performed in a 269 number of ways and with various entities participating in the process. 270 One illustrative method for Dynamic CAR Discovery is given below. 272 According to this method, an MN dynamically obtains information about 273 the available ARs for handoff, along with their capabilities. This is 274 done after the handoff trigger is generated. When the MN detects an 275 AR that has capabilities matching its preferences, the MN may notify 276 the currently serving AR to perform a handoff to this AR using one or 277 more of the seamless handoff protocols. The advantage of this method 278 is that the MN has fine-grained control over the TAR selection. 279 However, this method generates more radio traffic during the CAR 280 discovery step. This is because capability information is sent to the 281 MN over the air. Also, it is required that the MN can receive 282 IP-level capability information from the GAARs and negotiate 283 requirements with the GAARs, while still being connected to the 284 current AR. 286 Dynamic CAR Discovery is shown in Figure 2. 288 -------------------------------------------------------------- 289 | | 290 | GAARs identified at handoff time | 291 | | | 292 | | Capability identification | 293 | | | 294 | v | 295 | CARs for MN's handoff identified | 296 | | | 297 ---------------------------|---------------------------------- 298 | 299 | TAR selection at the 300 | time of handoff 301 v 302 Unique TAR identity 304 Figure 2: Dynamic CAR Discovery 306 4.3 Hybrid CAR Discovery 308 In practice, a hybrid of the Anticipated and Dynamic CAR discovery 309 approaches may be used. For example, in the hybrid approach, the GAAR 310 discovery and much of the capability identification may be performed 311 prior to handoff, while the remaining capability identification may 312 happen during the handoff process. But,there are other 313 alternatives too. 315 5. SPECIFIC ISSUES IN CAR DISCOVERY 317 The following sections describe the specific issues in the CAR 318 discovery, may it be done in anticipated, dynamic or hybrid way. 320 5.1 Identifying GAARs 322 A basic requirement for a new AR to be considered as a CAR for MN's 323 handoff is that the coverage area of the new AR be "geographically" 324 adjacent to or overlapping with that of the AR currently serving the 325 MN. In other words, a new AR must be a GAAR. Note, the geographical 326 vicinity of the coverage areas of two ARs is not necessarily implied 327 by their "logical" adjacency. Logical adjacency of two ARs means that 328 there is just one IP hop between the two ARs, while the adjacency of 329 the coverage areas of two ARs implies that the MN can actually move 330 from the coverage area of one AR to another (GAARs have APs whose 331 coverage areas are adjacent or overlapping). Conversely, GAARs need 332 not be logically adjacent, and may even have IP addresses in 333 different administrative domains. 335 The MIP fast handoff protocols specified in [3] and [4] or the 336 context transfer framework specified in [6] require that the current 337 AR or Foreign Agent (FA) (generically called ARs here for short) have 338 a list of ARs to which a MN could be handed over. In other words, the 339 current AR has a list of CARs. There is no reason, a priori, why 340 these CARs need to in topologically adjacent subnets. A CAR could 341 potentially be in a completely different BGP autonomous system. The 342 only requirement is that the corresponding APs be geographically 343 adjacent. Fig. 3 illustrates the problem. 345 BGP Autonomous BGP Autonomous 346 System A System B 348 +----+ +----+ 349 | BR |---> The Internet <---| BR | 350 +----+ (aka Cyberspace) +----+ 351 / \ 352 / \ 353 +----+ +----+ 354 | IR | | IR | 355 +----+ +----+ 356 | | 357 | | 358 +----+ +----+ 359 | AR | | AR | 360 +----+ +----+ 361 | | 362 |___________________ ________________| 363 | | | | 364 ... | -- -- | ... 365 | \/ \/ | 366 | | 367 |_______ ______| 368 | | | | 369 | -- -- | The Physical World 370 | \/ \/ | (aka Geospace) 371 | | 372 |______ _______| 373 | | 374 -- -- -- 375 \/ = AP \/ \/ 377 Figure 3: GAAR Discovery Problem 379 In the figure, the APs are shown connected to ARs in completely 380 different BGP autonomous systems, but the same problem occurs 381 if the APs are geographically adjacent and the ARs are in subnets 382 that are topologically distant within an autonomous system. The 383 criterion for an AR to be a candidate for an MN's handoff is the 384 geographical adjacency of the AP served by it to that of the AP to 385 which the MN is currently attached, and not the topological adjacency 386 of the corresponding ARs. Hence, IP routing protocols, such as OSPF 387 [8] or BGP [9], are not the solutions to GAAR discovery problem. 389 One approach is to manually configure this geographical neighborhood 390 at each AR. However, such an approach has disadvantages and in many 391 cases, may not be feasible. For instance, the GAARs may be under 392 different administrative control, and thus, are not informed about 393 each other's presence. Even within the same administrative domain, 394 the manual configuration approach demands much network planning in 395 terms of the coverage areas of different ARs. Finally, the manual 396 configuration approach is not suitable if the ARs can be physically 397 relocated or their coverage area changed, thus altering the 398 geographical scope of their coverage areas. Such a scenario is very 399 common when ARs are temporarily introduced in hot spots. Clearly, a 400 more automatic and dynamic mechanism is needed to discover GAARs 401 without much administrative intervention. 403 For the Anticipated CAR Discovery method described in Section 4.1, 404 the process of identifying GAARs requires a protocol that allows ARs 405 to exchange the information about the geographical adjacency of their 406 APs, in advance of handoff. In the Dynamic CAR Discovery method 407 described in Section 4.2, the MN automatically serves as the judge of 408 whether an AR is a GAAR. In the latter case, if the MN can hear a 409 Router Advertisement of the new AR, then the new AR is GAAR. 411 5.2 Identifying capabilities of GAARs: 413 Although not common now, the future generation mobile networks may 414 consist of ARs that are GAARs of each other, but are heterogeneous in 415 administrative control, functionality, link layer technology and 416 resources. An MN that is attached to a given AR may have specific 417 requirements as regards these parameters. For example, the MN may 418 need some hardware or software support from the AR or need some 419 application servers topologically close to the AR, to run certain 420 IP-based applications. Support for QoS, security, multicast, header 421 compression etc. are some other aspects that need to be considered 422 when choosing the CAR for MN's handoff. It may also be required to 423 assure some security association, policy agreement or billing 424 contract between the current AR and its GAARs in order to allow 425 MN's handoff between them. Finally, the access routers that are GAARs 426 of each other need to exchange information regarding the 427 correspondence between their IP addresses and the identities of the 428 APs (which the MN can listen to) that are connected to them. 430 Clearly, a protocol is needed that would enable the functions such as 431 solicitation and exchange of capability information among MN, ARs and 432 other network entities. 434 6. SECURITY CONSIDERATIONS 436 CAR discovery may allow other nodes to learn the following pieces of 437 information about an AR: 439 - Physical location 440 - Capabilities 441 - State of capabilities. 443 Malicious nodes may use this kind of information to launch attacks of 444 the DoS-style and/or service hijacking. Therefore, the following 445 topics should be covered in any protocol developed for CAR discovery: 447 - Authentication of nodes 448 - Security associations between nodes 449 - Message/payload encryption. 451 7. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM 453 The simplest possible discovery solution is to statically configure 454 the ARs in two geographically adjacent domains with the IP addresses 455 of their counterparts in the other domain. This solution is 456 impractical, particularly when the geographically adjacent domain 457 belongs to another administrative entity, such as a different 458 Wireless ISP (WISP). The neighboring WISP may decide to reconfigure, 459 add subnets, or remove them, as traffic patterns change. Propagating 460 those changes into static configurations would result in significant 461 availability lags. 463 Another solution is to use a simple directory based discovery 464 solution, such as DNS [10], LDAP [11], or SLP [12]. Attribute-based 465 discovery mechanisms such as LDAP and SLP could potentially handle 466 non-geographic capabilities, such as radio technology, but geographic 467 information may be difficult to cast into the form of attribute/value 468 pairs. In addition, information on changes in AR availability needs 469 to propagate dynamically between ARs rather than requiring the ARs to 470 explicitly ask for it. Finally, the client-server nature of these 471 protocols has the associated scalability and robustness concerns. 473 8. ACKNOWLEDGMENTS 475 Special thanks are due to John Loughney (Nokia) for his input 476 during the preparation of this document. 478 9. REFERENCES 480 [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. 482 [2] Mobility Support in IPv6, D. Johnson and C. Perkins, 483 draft-ietf-mobileip-ipv6-13.txt, 484 work in progress, November 2000. 486 [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 487 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 488 work in progress, February 2001. 490 [4] Fast handoffs for Mobile IPv6, MIPv6 handoff Design Team, 491 draft-ietf-mobileip-fast-mipv6-01.txt, 492 work in progress, April 2001. 494 [5] Problem Description: Reasons For Performing Context Transfers 495 Between Nodes in an IP Access Network, O. H. Levkowetz et. al., 496 draft-ietf-seamoby-context-transfer-problem-stat-01.doc, 497 work in progress, May 2001. 499 [6] General requirements for a context transfer framework, H. Sayed 500 et. al., draft-ietf-seamoby-ct-reqs-00.txt, 501 work in progress, May 2001. 503 [7] Buffer Management for Smooth handoffs in Mobile IPv6, 504 G. Krishnamurthi, R. Chalmers, and C. Perkins, 505 draft-krishnamurthi-mobileip-buffer6-01.txt, 506 work in progress, March 2001. 508 [8] Open Shortest Path First protocol, Version 2, J. Moy, RFC 2328, 509 April 1998. 511 [9] A Border Gateway Protocol 4 (BGP-4), edited by Y. Rekhter and 512 T. LI, RFC 1771, March 1995. 514 [10] Domain Name System Structure and Delegation, J. Postel, RFC 1591, 515 March 1994. 517 [11] Lightweight Directory Access Protocol, W. Yeong, T. Howes, and 518 S. Kille, RFC 1777, March 1995. 520 [12] Service Location Protocol, Version 2, E. Guttman et. al., 521 RFC 2608, June 1999. 523 10. AUTHORS' ADDRESS 525 Dirk Trossen 526 Communication Systems Laboratory 527 Nokia Research Center 528 5 Wayside Road 529 Burlington, MA 01803, USA 531 Phone: +1 781 993 3605 532 Fax: +1 781 993 1907 533 E-mail: dirk.trossen@nokia.com 535 Govind Krishnamurthi 536 Communication Systems Laboratory 537 Nokia Research Center 538 5 Wayside Road 539 Burlington, MA 01803, USA 541 Phone: +1 781 993 3627 542 Fax: +1 781 993 1907 543 E-mail: govind.krishnamurthi@nokia.com 545 Hemant Chaskar 546 Communication Systems Laboratory 547 Nokia Research Center 548 5 Wayside Road 549 Burlington, MA 01803, USA 551 Phone: +1 781 993 3785 552 Fax: +1 781 993 1907 553 E-mail: hemant.chaskar@nokia.com 555 James Kempf 556 DoCoMo Communication Laboratories, USA 557 181 Metro Drive, Suite 300 558 San Jose, CA 95110, USA 560 Phone: +1 408 451 4711 561 Email: kempf@docomolabs-usa.com