idnits 2.17.1 draft-ietf-seamoby-paging-problem-statement-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 19 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 610 has weird spacing: '... copied and ...' == Line 611 has weird spacing: '...s, and deriv...' == Line 613 has weird spacing: '...ed, in whole...' == Line 614 has weird spacing: '...hat the above...' == Line 616 has weird spacing: '...such as by r...' == (4 more instances...) -- 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 (Feburary 2001) is 8504 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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-optim-10 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT James Kempf, Editor 3 Category: Informational Sun Microsystems 4 Title: draft-ietf-seamoby-paging-problem-statement-02.txt 5 Date: Feburary 2001 6 Paging Problem Statement 8 Status of this Memo 10 This document is a working group contribution for the Seamoby Working 11 Group. 13 Distribution of this memo is unlimited. 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Copyright (C) The Internet Society 2001. All Rights Reserved. 36 Abstract 38 The IESG has requested that the Seamoby Working Group develop a 39 problem statement about the need for additional protocol work to 40 support paging for seamless IP mobility. The paging design team 41 interpreted this as direction to examine whether location of a mobile 42 node in power saving mode can be supported by the existing Mobile 43 IPv4 and Mobile IPv6 protocols given existing radio link protocols. 44 This draft describes paging, assesses the need for IP paging, and 45 presents a list of recommendations for Seamoby charter items 46 regarding work on paging. The results are specifically directed 47 toward the task undertaken by the design team, and are not meant to 48 be the definitive word on paging for all time, nor to be binding on 49 Seamoby or other working groups, should the situation with regard to 50 IP mobility protocols or radio link support undergo a major change. 52 1.0 Introduction 54 Many existing radio link protocols and mobile systems support 55 location of and radio link establishment with mobile nodes that are 56 in power saving mode and hence are not actively listening for 57 delivery of IP packets all the time or are not listening on the radio 58 channels normally associated with delivering IP traffic to mobile 59 nodes. This functionality allows mobile nodes to reduce power 60 consumption and decreases signaling load on the network for tracking 61 mobiles that are not actively participating in IP packet generation 62 or reception. 64 When a mobile is in low power consumption mode, special steps need to 65 be taken to locate the mobile. These steps differ depending on the 66 radio link, but the generic name for this process is paging. 68 In this document, after some initial definitions and material related 69 to more clearly explaining what paging is, we assess the need for 70 paging in existing IP mobility protocols (namely Mobile IP [1] [2]). 71 We then develop a list of work items for the Seamoby working group 72 related to this need. Note that the discussion in this document and 73 the conclusions regarding work items are directed toward existing IP 74 mobility protocols and existing radio link protocols. Should a major 75 change occur in radio link support or the available IP mobility 76 protocols, such as the introduction of a micromobility protocol for 77 IP, the issues examined in this document may need to be revisited. 79 2.0 Definitions 81 The following definitions are relevent with respect to clarifying the 82 paging functionality: 84 Dormant Mode - A state in which the mobile restricts its ability 85 to receive normal IP traffic by reducing monitoring of radio 86 channels. This allows the mobile to save power and reduces 87 signaling load on the network. 89 Time-slotted Dormant Mode - A dormant mode implementation in which 90 the mobile alternates between periods of not listening for any 91 radio traffic and listening for traffic. Time-slotted dormant mode 92 implementations are typically synchronized with the network so the 93 network can deliver traffic to the mobile during listening 94 periods. Additionally, the mobile may be restricted to listening 95 on specific signaling channels that, according to current 96 practice, are not typically used to carry IP traffic. 98 Paging - As a consequence of a mobile-bound packet destined for a 99 mobile currently in dormant mode, signaling by the network through 100 radio access points directed to locating the mobile and 101 establishing a last hop connection. This messaging is in addition 102 to simply delivering the packet to the mobile, i.e. last hop 103 routing of packets is NOT considered to be paging. 105 Paging Area - Collection of radio access points that are signaled 106 to locate a dormant mode mobile node. A paging area does not 107 necessarily correspond to an IP subnet. A dormant mode mobile node 108 may be required to signal to the network when it crosses a paging 109 area boundary, in order that the network can maintain a rough idea 110 of where the mobile is located. 112 Paging Channel - A radio channel dedicated to signaling dormant 113 mode mobiles for paging purposes. By current practice, the 114 protocol used on a paging channel is usually dictated by the radio 115 link protocol, although some paging protocols have provision for 116 carrying arbitrary traffic (and thus could potentially be used to 117 carry IP). 119 Traffic Channel - The radio channel on which IP traffic to an 120 active mobile is typically sent. This channel is used by a mobile 121 that is actively sending and receiving IP traffic, and is not 122 continuously active in a dormant mode mobile. For some radio link 123 protocols, this may be the only channel available. 125 Paging Area Registrations - Signaling from a dormant mode mobile 126 node to the network when the mobile node crosses a paging area 127 boundary to establish the mobile node's presence in the new paging 128 area. 130 3.0 Discussion of Paging 132 Dormant mode is advantageous to a mobile node and the network for the 133 following reasons: 135 - Power savings. By reducing the amount of time the mobile is 136 required to listen to the radio interface, the drain on the mobile 137 node's battery is reduced. 139 - Reduced signaling for location tracking. By requiring the mobile 140 to only signal when it crosses a paging area boundary rather than 141 when it switches between radio access points, the amount of 142 signaling for tracking the mobile is reduced because paging areas 143 typically contain many radio access points. 145 - Reduced router state. By removing the need for routers to keep 146 the mobile node's binding in their binding caches, the amount of 147 state in routers is reduced, because the number of mobile nodes in 148 dormant mode may be considerably more than those that are active. 150 In existing radio link protocols, there is a clear distinction 151 between those protocols that support dormant mode only and those that 152 support dormant mode with paging. Radio link protocols that do not 153 support paging have no paging areas, no dedicated paging channel, and 154 no radio link protocol specifically directed towards locating a 155 dormant mode mobile, while radio link protocols that do support 156 paging have these features. Although generalizations always run the 157 risk of being contradicted by specific exceptions, the following 158 comparison of existing radio link protocol support for these two 159 cases may be instructive. 161 3.1 Dormant Mode Support Only 163 In radio link protocols that only support dormant mode, a dormant 164 mode mobile node typically operates in time slotted mode and there is 165 only one radio channel available, namely the traffic channel. The 166 mobile node periodically wakes up, and, synchronously, the radio 167 access point in the network with which the mobile node is associated 168 delivers any IP packets that have arrived while the mobile node was 169 asleep. Radio access points are required to buffer incoming packets 170 for dormant mode mobiles; exactly how many packets and how long they 171 are buffered are implementation dependent. 173 If the mobile node happens to move out of range of the access point 174 with which it was associated, while it is in dormant mode, it 175 discovers this when it awakens and reassociates with a new access 176 point. The new access point then contacts the old access point over 177 the wired backbone, the old access point sends any buffered packets, 178 and the new access point delivers them to the mobile. 180 Radio link protocols with dormant mode support only are typically 181 wireless LAN protocols in unlicensed spectrum in which the mobile 182 node is not charged for using a traffic channel, and hence there is 183 no need for conserving spectrum usage. 185 3.2 Dormant Mode with Paging Support 187 In radio link protocols with support for paging, the radio link 188 typically supports more than one channel. A dormant mode mobile node 189 may operate in time slotted mode, periodically waking up to listen to 190 the paging channel, or it may simply listen to the paging channel 191 continuously. The important point is that the mobile does not listen 192 to nor transmit on a traffic channel while in dormant mode. 194 The radio access points are grouped into paging areas, and the radio 195 link protocol supports periodic signaling between the mobile and the 196 network only when the mobile crosses a paging area boundary, for the 197 purpose of giving the network a rough idea of the mobile's location 198 (paging area registrations). Some deployments of paging do not even 199 use paging area registrations. They use heuristics to determine where 200 the mobile is located when a packet arrives, in which case, no 201 signaling is required while the mobile is in dormant mode. 203 An incoming packet is directed to the paging area where the mobile 204 last reported, or the paging area is determined by heuristics. The 205 network performs a radio link page by sending out a signal on the 206 paging channel. The signal may be repeated until the mobile answers 207 or a timeout occurs. In the former case, the packet is delivered, in 208 the latter, the mobile is assumed to be unreachable. 210 Radio link protocols with paging support tend to be in licensed 211 spectrum where the network operator has an interest in reducing the 212 amount of signaling over traffic channels. Such reduction frees 213 traffic channel spectrum for revenue-producing use, and avoids 214 charging the customer for signaling overhead. 216 4.0 Is IP Paging Necessary? 218 In this section, we consider whether IP paging support is necessary. 219 We first consider radio link protocols that have no support for 220 paging. We then examine radio link protocols that have paging 221 support. As discussed in the introduction, the focus is on whether 222 the existing IETF mobility protocol, namely Mobile IP, requires 223 enhancement. We also briefly discuss the relationship between paging 224 and a potential future micromobility protocol. 226 4.1 IP Paging for Dormant Mode Only Radio Links 228 One possible justification for IP paging is for radio links that do 229 not support paging. The reasoning is that an IP paging protocol could 230 allow location of a dormant mode mobile in radio networks that do not 231 support paging in the radio protocol. 233 An important point to keep in mind when considering this possibility 234 is that, for radio links that do support paging, paging is typically 235 used to locate mobiles for which the network has a rough idea of 236 where the mobile is located. More specifically, in order to conserve 237 signaling between the network and the mobile and to reduce power 238 drain on the mobile, the mobile only updates the network about its 239 location when it crosses a paging area boundary (if even then), which 240 is far less frequent than when it crosses a radio access point 241 boundary. If IP paging is to be of any use to radio link protocols 242 that do not support paging, it must also be the case that it allows 243 the network to maintain a rough idea of where the mobile is, 244 otherwise, the amount of signaling involved in tracking the mobile 245 and power drain on the mobile is not reduced. 247 However, as the description in the previous section indicates, for 248 radio links without paging support, the network always has an *exact* 249 idea of where the mobile is located. When the mobile moves into 250 range of a new radio access point, it re-registers with the access 251 point in that cell allowing the new access point to contact the old 252 and deliver any buffered traffic. Additionally, the new access point 253 at that time may choose to deliver a foreign agent advertisement (for 254 Mobile IPv4) or router advertisement (for Mobile IPv6) to the mobile 255 if the mobile node has changed subnets, so that the mobile can 256 perform Mobile IP re-registration in order to make sure its IP 257 routing is current. There is absolutely no ambiguity in the mobile's 258 location as far as the network is concerned, and so the network can 259 continue to route packets to the mobile node while the mobile is in 260 dormant mode with assurance (modulo buffer overflows and timeouts at 261 the radio access point) that the packets will be delivered to the 262 mobile the next time it wakes up from dormant mode. 264 As a consequence, IP paging provides no advantages for radio link 265 protocols in which the radio link does not have support for paging. 267 4.2 IP Paging for Radio Links with Paging Support 269 In radio links that do support paging, there are two cases to 270 consider: networks of radio links having a homogeneous radio 271 technology and networks of radio links having heterogeneous radio 272 technologies. We examine whether Mobile IP can support dormant mode 273 location for both these cases. 275 4.2.1 Homogeneous Technology Networks 277 For homogeneous technology networks, the primary issue is whether 278 signaling involved in Mobile IP is enough to provide support for 279 locating dormant mode mobile nodes. Subnets constitute the unit of 280 signaling for presence in IP. When a mobile node moves from one 281 subnet to another, Mobile IP signaling is required to change the 282 mobile's care-of address. This signaling establishes the mobile's 283 presence in the new subnet. Paging areas constitute the unit of 284 signaling for dormant mode mobile presence at the radio level. Paging 285 area registrations or heuristics are used to establish a dormant mode 286 mobile's presence in a particular paging area. 288 If paging area registrations can always serve to trigger Mobile IP 289 registrations, there is no need for an IP paging protocol because the 290 network (specifically the home or hierarchical agent) will always 291 have an up-to-date picture of where the mobile is and can always 292 route packets to the mobile. The key determining factor with regard 293 to whether paging area registrations can be used in this fashion is 294 how subnets are mapped into paging areas. If it is always possible 295 to map the two such that a paging area registration can serve as a 296 transport for a Mobile IP registration, or some other technique (such 297 as network assisted handoff [3] [4]) can be used to transfer the 298 Mobile IP registration, then no IP paging protocol is needed. 300 In general, the mapping between paging areas and subnets can be 301 arbitrary, but we consider initially a smooth subset relationship, in 302 which paging areas are subsets of subnets or vice versa. Network 303 topologies in which one subnet is split between two or more paging 304 areas are therefore eliminated. The restriction is arbitrary, but by 305 starting here, we can discover whether additional work is needed. We 306 also consider a case where paging area registrations in the radio 307 layer protocol are always done. This is also optimistic. 309 There are three cases: 311 1) The topological boundaries of the paging area and subnet are 312 identical. 314 2) Multiple paging areas are part of the same subnet. 316 3) Multiple subnets are part of the same paging area. 318 Each case is considered in the following subsections. 320 4.2.1.1 Subnet and Paging Area Boundaries Identical 322 In the case where radio paging areas map one to one onto IP subnets 323 (and hence Mobile IPv4 foreign agents or IPv6 access routers), it is 324 possible to use radio link paging together with Mobile IP handoff 325 techniques for the network to track the mobile's location. If the 326 paging area update protocol supports sending arbitrary packet data 327 over the paging channel, the access router or foreign agent can send 328 a router advertisement or foreign agent advertisement to the mobile 329 as part of the signal that the mobile has entered the new paging 330 area, and the mobile can send a Mobile IP registration as part of the 331 paging area update. For other cases, enhancements to Mobile IP 332 network-assisted handoff techniques can allow the network to track 333 the mobile as it moves from paging area (== subnet) to paging area. 335 Other uses of the Mobile IP registration protocol are also possible 336 depending on the level of paging support for packet data. As a 337 consequence, the home or hierarchical agent has complete knowledge of 338 routes to the mobile and can route packets to the foreign agent or 339 access router. Radio layer paging may be needed at the foreign agent 340 or access router in order to re-establish a traffic channel with the 341 mobile, but no IP paging is required. 343 4.2.1.2 Multiple Paging Areas Map into One Subnet 345 The case where multiple radio paging areas map to a single IP subnet 346 is the same as above, with the exception that the last hop Mobile 347 IPv4 foreign agent or IPv6 access router for the subnet performs 348 paging in multiple paging areas to locate the mobile. 350 4.2.1.3 Multiple Subnets Map into One Paging Area 352 In the case where a single radio paging area maps onto multiple IP 353 subnets, it is not possible to directly use Mobile IP handoff between 354 last hop access routers or foreign agents to track the mobile's 355 location as it moves, because the mobile does not signal its location 356 when it changes subnets. Within the set of subnets that span the 357 paging area, the mobile's movement is invisible to the L2 paging 358 system, so a packet delivered to the mobile's last known location may 359 result in a page that is answered in a different subnet. 361 Consider the following example. Suppose we have a network in which 362 there are two paging areas, PA(1) and PA(2). Within each, there are 363 many subnets. Consider a mobile that moves from PA(1) to PA(2), and 364 enters PA(2) at subnet X. Using the paging area registration, it 365 signals the network that it has moved, and suppose that the paging 366 area registration contains a Mobile IP registration. The agent 367 handling the L2 paging protocol sends the registration to the 368 home/hierarchical agent (or perhaps it simply gets routed). The 369 home/hierarchical agent now knows that the mobile has a CoA in subnet 370 X, as does the mobile. After the mobile has completed the paging 371 area registration/Mobile IP registration, it goes back to sleep. 373 But the mobile does not stop in subnet X, it keeps moving while in 374 dormant mode, when it is doing no signaling (L2, mobile IP or other) 375 to the network. It moves from subnet X where it originally entered 376 the paging area clear to the other side of the paging area, in a 377 completely different subnet, subnet Y. 379 Suppose a packet comes into the home/hierarchical agent for this 380 mobile. Because the home/hierarchical agent believes the mobile is in 381 subnet X, it sends the packet to the access router or foreign agent 382 for subnet X. The packet gets to the access router or foreign agent, 383 and the access router or foreign agent performs a radio page for the 384 mobile in subnet X. Since the mobile isn't in subnet X, it wakes up 385 in subnet Y because the radio page propagates throughout the paging 386 area. It does a mobile IP reregistration because it sees that it is 387 in a new subnet, but the packet at the access router or foreign agent 388 in subnet X can't get to the mobile. 390 Without any further support, the access router or foreign agent in 391 subnet X drops the packet. The only way to get the packet to the 392 mobile node from the access router or foreign agent is for the mobile 393 node to send a binding update to the access router or foreign agent 394 when it wakes up in the new subnet. Once the access router or foreign 395 agent has the new binding, it can forward the packet. Some smooth 396 handoff techniques depend on sending binding updates to foreign 397 agents [5], so arranging for the mobile node to send a binding update 398 would be possible. In IPv6, it becomes less attractive because of the 399 need for security on the binding update. In either case, the result 400 would be yet more Mobile IP signaling before the packet could be 401 delivered, increasing the amount of latency experienced by the 402 mobile. 404 While it may be possible with enhancements to Mobile IP to handle the 405 case, the enhancements would probably introduce more latency and 406 signaling into the initial connection between the mobile and the 407 network when the mobile awakes from dormant mode. An IP paging 408 protocol between the home or hierarchical agent and a paging agent in 409 the paging area would serve to reduce the amount of latency involved 410 in delivering the initial packet. With IP paging, the arrival of the 411 packet at the home/hierarchical agent results in an IP page to a 412 paging agent in the last reported paging area. The paging agent 413 performs an L2 page to the mobile. The mobile answers the page with a 414 mobile IP registration to the home/hierarchical agent and the 415 home/hierarchical agent sends the packet. The home/hierarchical agent 416 and the mobile already have a security association, so there is no 417 need to negotiate one, and buffering of the first packet and any 418 further incoming packets prior to the mobile IP registration is 419 handled by the home/hierarchical agent rather than a router at the 420 edge, so the edge routers can be simpler. Finally, the 421 home/hierarchical agent can start routing to the mobile as soon as 422 the registration comes in. 424 4.1.2.4 More Complex Homogeneous Network Cases 426 Up until now, the discussion has not identified any case where the 427 problem of locating and delivering the first packet to a dormant mode 428 mobile could not be handled by Mobile IP with enhancements. IP 429 paging serves as a promising optimization in the multiple subnets to 430 single paging area case, but in principle additional Mobile IP 431 signaling (potentially lots in the case of IPv6 if a security 432 association is needed) could handle the problem. However, the 433 examples examined in the above sections are really best-case. In 434 practice, the mapping of subnets to paging areas is likely to be far 435 less clear cut, and the use of paging area registrations far less 436 common than has been assumed in these cases. 438 Requiring network operators to make paging areas and subnets conform 439 to a subset relationship that would allow mobile IP signaling to do 440 double duty as paging area updates is unrealistic. In practice, 441 paging areas often overlap and there is often not even a clear subset 442 relationship between paging areas themselves. Some radio protocols, 443 such as wCDMA [6], allow different mobile terminals in the same 444 geographical area to have different paging area identifiers. Working 445 through each case and trying to identify whether Mobile IP needs 446 enhancement would probably result in a much more complex result than 447 having a simple IP paging protocol that allows a home/hierarchical 448 agent to notify an L2 agent in the paging area when a new packet 449 comes in. 451 Finally, requiring operators to always turn on paging area 452 registrations is unacceptable, and using Mobile IP registrations 453 won't work if paging area registrations are not done. The above 454 description is ideal with regard to signaling between the mobile node 455 in dormant mode and the network. Anecdotial evidence indicates that 456 most operators do not turn on paging area registrations, they use 457 heuristics to determine where to page for the mobile. If the 458 operator does not turn on paging area registrations, there is no way 459 for the mobile to report its position when it changes paging area, 460 hence no L2 vehicle for potential dormant mode use of Mobile IP. 462 4.2.2 Heterogeneous Technology Networks 464 In a network composed of links with multiple technologies, the 465 problems identified above become multiplied. Using Mobile IP becomes 466 even more cumbersome, because the subnet to which the initial packet 467 is delivered, besides not being in the same subnet on which the 468 dormant mode mobile is located, may be on a radio network which the 469 user would actually not prefer to use in their current location. This 470 could happen, for example, if the mobile moved inside a building and 471 radio coverage on one interface became weak or nonexistent, or if the 472 user had a choice of a cheaper or higher bandwidth connection. The 473 mobile may actually no longer be listening or reachable on the paging 474 channel of the old network, so when the old access router or foreign 475 agent pages on the old radio network, the mobile, which is now 476 listening only for pages on the new network, may not answer, even 477 though it is reachable on the new network. Arranging for pages in 478 multiple radio networks is a possibility, but without an L3 paging 479 protocol to abstract away from the L2 details, the details of each L2 480 protocol must be handled separately. 482 A paging protocol that unifies paging across multiple radio 483 technologies therefore looks attractive. There may be commonalities 484 in the corresponding radio paging protocols that allow a mapping to 485 be established between the radio protocols and an abstract IP paging 486 protocol. For example, assume we have a common paging area identifier 487 defined at the IP layer that is mapped to each radio paging protocol 488 by the access points. An IP paging message containing the identifier 489 is sent to multiple access points, where the appropriate radio paging 490 message is sent based on the particular technology implemented by the 491 access points. The results are then returned by the radio paging 492 responses, mapped back into IP by the access points, and delivered 493 back to the origin of the page. 495 An additional case to consider is when a single subnet consists of 496 multiple radio access tchnologies. A wireless access point usually 497 provides L2 bridge behavior to the wired link with which it is 498 connected. If two access points with incompatible technologies and 499 non-overlapping cells are connected to the same subnet, a mobile node 500 with interfaces to both technologies would need paging from both 501 technologies. If reachability can be established simply by ARP or 502 neighbor discovery, no IP paging is needed. However, note that ARP or 503 neighbor discovery requires that a functional traffic channel be 504 available to the mobile, since these protocols are typically 505 implemented for wired networks in which a single channel exists on 506 which all IP traffic is delivered. If the mobile is currently in the 507 sleep phase of a time-slotted dormant mode, or if it is listening to 508 a paging channel it will fail to respond to these requests. In this 509 case, some means of triggering a radio page from IP is necessary to 510 find the mobile. Modifying ARP or neighbor discovery to utilize a 511 paging channel if available is a possible, if somewhat messy, 512 alternative, but a dedicated location protocol may be somewhat 513 cleaner. 515 4.3 Paging and Micromobility 517 If the Seamoby Working Group decides that an IP micromobility 518 protocol is necessary, then the above analysis is no longer complete. 519 A micromobility protocol may require some type of paging support. The 520 design team does not want to include any further discussion of paging 521 and micromobility at this point, because it is not clear whether 522 micromobility will be pursued by Seamoby and hence such discussion 523 would be premature. 525 5.0 What Exactly is the Problem? 526 While the above analysis has identified situations in which location 527 of a mobile in dormant mode may require some action at the IP layer, 528 it is important keep in mind what the problem is. The problem to be 529 solved is the location of a mobile node because it has moved while in 530 dormant mode. IP paging is one solution to the problem, there may be 531 others. 533 6.0 Recommendations 535 The design group recommends the following charter items for Seamboy: 537 1) Since the design group has identified several network 538 deployment scenerios where existing Mobile IP technology cannot 539 find a mobile in dormant mode, protocol work is necessary to 540 define a way for the network to find a mobile that is currently in 541 dormant mode. 543 2) The work defined above should be pursued in a way that is 544 maximally consistent with Mobile IP and other existing IETF 545 protocols. The work should also generate recommendations about how 546 to achieve the best match between existing radio paging protocols 547 and IP. 549 3) If the Seamoby working group decides to pursue a micromobility 550 protocol that requires paging, the Seamoby group should undertake 551 the design of a new paging protocol within the context of that 552 work. 554 4) There is some evidence that cellular operators' deployments of 555 paging are highly variable, and may, in fact, be suboptimal in 556 many cases with respect to supporting IP. The Seamoby working 557 group should write a BCP which explains how to perform IP subnet 558 to paging area mapping and which techniques to use when, so 559 network designers in wireless networks have a guide when they are 560 setting up their networks. 562 7.0 Acknowledgements 564 The editor would like to thank the Seamoby paging design team for 565 helping formulate the first draft of the document. Jari Malinen 566 contributed text to Section 4.2. Hesham Soliman, Karim El-Malki, and 567 Behcet Sarikaya contributed critical commentary on the first draft, 568 which was important in sharpening the reasoning about what can and 569 can't be expected in the absence of radio layer paging support and 570 how Mobile IP might be used to support dormant mode location. 572 8.0 References 573 [1] C. Perkins, editor. "IP Mobility Support", RFC 2002, October, 1996. 575 [2] Johnson, D., and C. Perkins, "Mobility Support in IPv6", draft- 576 ietf-mobileip-ipv6-13.txt, a work in progress. 578 [3] Calhoun, P., et. al., "Foreign Agent Assisted Hand-off", draft- 579 calhoun-mobileip-proactive-fa-03.txt, a work in progress. 581 [4] Tsirtsis, G., Editor, "Fast Handovers for Mobile IPv6", draft- 582 designteam-fast-mipv6-01.txt, a work in progress. 584 [5] Perkins, C. and Johnson, D., "Route Optimization in Mobile IP", 585 draft-ietf-mobileip-optim-10.txt, a work in progress. 587 [6] Holma, H. and Toskala, A., "WCDMA for UMTS: Radio Access for Third 588 Generation Mobile Communication," John Wiley and Sons, New York, 589 2000. 591 9.0 Editor's Address 593 Questions about this memo can be directed to: 595 James Kempf 596 Sun Labs California 597 Sun Microsystems, Inc. 598 901 San Antonio Rd., UMPK15-214 599 Palo Alto, CA, 94303 600 USA 602 Phone: +1 650 786 5890 603 Fax: +1 650 786 6445 604 E-Mail: james.kempf@sun.com 606 10.0 Full Copyright Statement 608 Copyright (C) The Internet Society (2001). All Rights Reserved. 610 This document and translations of it may be copied and furnished to 611 others, and derivative works that comment on or otherwise explain it 612 or assist in its implementation may be prepared, copied, published and 613 distributed, in whole or in part, without restriction of any kind, 614 provided that the above copyright notice and this paragraph are 615 included on all such copies and derivative works. However, this docu- 616 ment itself may not be modified in any way, such as by removing the 617 copyright notice or references to the Internet Society or other Inter- 618 net organizations, except as needed for the purpose of developing 619 Internet standards in which case the procedures for copyrights defined 620 in the Internet Standards process must be followed, or as required to 621 translate it into languages other than English. The limited permis- 622 sions granted above are perpetual and will not be revoked by the 623 Internet Society or its successors or assigns. This document and the 624 information contained herein is provided on an "AS IS" basis and THE 625 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 626 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 627 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 628 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 629 PARTICULAR PURPOSE."