idnits 2.17.1 draft-ietf-mobileip-paging-hawaii-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 4) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security' ) ** 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 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 371 has weird spacing: '... entry entr...' -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'N' on line 588 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1305 (ref. '3') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Ramjee / T. La Porta 2 INTERNET-DRAFT Lucent Bell Labs 3 draft-ietf-mobileip-paging-hawaii-01.txt L. Li 4 7 Jul 2000 Cornell University 5 Expires: 7 Jan 2001 7 Paging support for IP mobility 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines extensions to the HAWAII IP micro-mobility 33 protocol to enable paging. Paging facilitates efficient power 34 management at the mobile host by allowing the host to update the 35 network less frequently at the cost of providing the network with 36 only approximate location information. The protocol extensions 37 described here provide a means for the network to determine the exact 38 location of a mobile host before delivering packets destined to the 39 mobile host. 41 Contents 43 1 Changes from version 00 3 45 2 Introduction 3 46 2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 49 2.4 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 50 2.4.1 State Synchronization . . . . . . . . . . . . . . . . 8 51 2.4.2 Application of IP Multicasting Protocol . . . . . . . 9 52 2.4.3 Distributed Paging . . . . . . . . . . . . . . . . . . 10 53 2.4.4 Soft-State . . . . . . . . . . . . . . . . . . . . . . 10 54 2.4.5 Stale Paging Entry . . . . . . . . . . . . . . . . . . 10 55 2.5 Protocol Correctness . . . . . . . . . . . . . . . . . . . . 11 57 3 Detailed Protocol Operation 11 58 3.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . 12 59 3.2 Mobile Host Processing . . . . . . . . . . . . . . . . . . . 14 60 3.3 Base Station/Router Processing . . . . . . . . . . . . . . . 15 62 4 Design Implications 18 63 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.2 Ease of Network Management . . . . . . . . . . . . . . . . . 18 65 4.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 19 67 5 Paging with Mobile-IP 19 68 5.1 HA Paging . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 5.2 FA Paging . . . . . . . . . . . . . . . . . . . . . . . . 20 71 6 Security 20 72 1 Changes from version 00 74 o Changed the HAWAII paging algorithm so that paging load can be 75 shared between routers and base stations based on a tunable 76 parameter. 77 o Added discussion on HA and FA paging. 79 2 Introduction 81 Mobile-IP is the current standard for supporting macro-mobility in IP 82 networks [4]. Recently there have been several proposals such as 83 Cellular IP [6] and HAWAII [5] for supporting micro-mobility. While 84 these solutions enable support for high mobility users in wide-area 85 wireless networks, they assume that the mobile host updates the 86 network on every handoff. This enables the network to know the exact 87 location of the host, i.e., the current base station for delivering 88 packets to the mobile host. 89 On the other hand, current wide area wireless data solutions such as 90 General Packet Radio Service (GPRS) [1] allow the mobile host to 91 operate in two distinct states - an active state where the network 92 knows the location of the mobile host's current base station, and a 93 standby state where the network knows only the approximate location 94 of the user, such as a set of base stations on which the mobile host 95 resides. One of the motivations for defining the standby state is 96 for reducing the host's battery power consumption by allowing the 97 mobile host to only notify the network when it moves out of a set of 98 base stations. If data packets for a mobile host in standby state 99 arrive into the wireless access network, the network "pages" the 100 mobile host in this set of base stations to determine the mobile 101 host's current base station before delivering the data packets. In 102 the GPRS network, this paging functionality is performed in a 103 centralized fashion by a Serving GPRS Service Node (SGSN) and can be 104 considered as a link layer function. 105 We envision the next generation wireless access network as a pure 106 IP-based network, where base stations will be IP addressable 107 entities. We believe mobility, as well as the paging functionality, 108 should be handled at the network (IP) layer. This enables the 109 deployment of a homogeneous, IP-based wireless access network that is 110 independent of the different wireless interfaces. Wireless link 111 specific processing is relegated only to the base stations. Thus, we 112 propose extensions to the IP layer software running in routers/base 113 stations in the access network to support paging. 114 Note that HAWAII [5] is a domain-based approach for supporting 115 mobility that maintains the mobile host's IP address unchanged across 116 mobility within the domain. Since a typical HAWAII domain will cover 117 one or more paging areas, extending HAWAII to implement paging seems 118 a logical choice. HAWAII uses specialized path setup schemes which 119 install host-based forwarding entries in specific routers to support 120 intra-domain micro-mobility. In this framework, adding paging 121 functionality to HAWAII involves augmenting the HAWAII forwarding 122 functionality with paging. Thus, we extend the HAWAII protocol with 123 paging functionality. 125 2.1 Goals 127 We have the following design goals: 129 o Achieve efficient power consumption at the mobile host by 130 limiting the location update traffic and using paging to locate 131 the mobile host when necessary. 133 o Perform paging in a scalable fashion. This involves pushing the 134 paging functionality closer to the base station. 136 o Perform paging in a distributed fashion. This involves being 137 able to page from any base station/router in the access network. 138 This eliminates single points of failure for enhanced 139 reliability. 141 o Support for different types of paging areas such as fixed, 142 hierarchical, and user-defined paging areas. 144 2.2 Assumptions 146 We assume that HAWAII operates as the micro-mobility protocol in the 147 access portion of the wireless network. We propose extensions to 148 HAWAII to support paging functionality. In Section 5, we discuss how 149 paging functionality can be applied to a basic Mobile-IP network, 150 albeit without some of the scalability and reliability advantages 151 that paging with HAWAII provides. 153 We also assume that there is link-level paging support on the 154 wireless link. This entails that a mobile host is able to detect 155 paging requests and identify its current paging area. There are 156 several ways in which this may be implemented. A typical solution, 157 used in current cellular networks, is to have the base stations send 158 paging requests on separate paging channels and send beacons with 159 base station and paging area identities periodically on a broadcast 160 channel. A mobile client monitoring these paging and broadcast 161 channels can then detect paging requests and changes in paging area. 162 Another solution is to let the mobile host query the base station by 163 sending link layer point to point messages. 165 Note that the paging functionality proposed in this draft is 166 necessary only if updating the network on every handoff of the mobile 167 host is expensive, for example, in terms of signaling load or battery 168 power consumption; mobile devices for which this is not an issue or 169 for devices that use wireless link protocols such as WaveLAN which 170 have no link-level paging support can simply utilize the basic HAWAII 171 proposal without the paging extension described in this draft. 173 2.3 Terminology 175 Domain 177 A division of the wireless access network. It consists of one or 178 more routers and multiple base stations. It will appear as a 179 subnet to routers external to the domain. 181 Domain Root Router 183 The gateway router into a domain is called the domain root router. 185 Active State 187 In active state, the mobile host updates the network on every 188 handoff. Thus, the network tracks the current base station of the 189 mobile host. 191 Standby State 193 In standby state, the mobile host reduces battery power 194 consumption by listening to only selective broadcast channels. 195 Furthermore, the mobile host updates the network of its location 196 only when it crosses a set of base stations, known as the paging 197 area. 199 Paging Area 201 The granularity to which the mobile user is tracked in standby 202 state. It consists of a set of base stations, typically defined 203 by a network administrator. In this draft, we identify these base 204 stations by a IP Multicast Group Address (MGA). 206 Routing Entry 208 A routing entry in the base stations and routers in the domain 209 specifies where to forward a packet for a given mobile host. It 210 is established by the HAWAII protocol. A routing entry for a 211 mobile host is present in selected routers/base stations when the 212 mobile host is in active state. 214 Paging Entry 216 A paging entry in the base stations and routers in the domain 217 specifies which set of base stations to page for a given mobile 218 host. It is established by the HAWAII protocol. A paging entry 219 for a mobile host is present in selected routers/base stations 220 when the mobile host is in active or standby state. 222 2.4 Protocol Overview 224 In this section, we present the protocol design for the paging 225 functionality within the HAWAII framework. We believe that mobile 226 devices would mostly operate in standby state, with brief periods in 227 active state. In the standby state, the mobile host conserves 228 significant battery power. The mobile host can switch to active 229 state immediately after receiving notification from the network that 230 data packets are destined for it. 232 Like today's cellular networks, it is not desirable for the mobile 233 host to update its location every time the mobile host moves to a 234 different base station. Therefore the network is not able to 235 maintain exact location information for the mobile host and instead 236 maintains only approximate location information. Location 237 information can be maintained in one place in the network such as the 238 domain root router (DRR). However, such a centralized approach 239 introduces a single point of failure and results in scalability 240 concerns. Therefore we favor a distributed approach. On the other 241 hand, maintaining paging information in every element in the access 242 network is also not desirable. This would require flooding the 243 location information to the entire HAWAII domain, which wastes 244 bandwidth and processing resources. Thus, our solution endeavors to 245 maintain the location information for a given mobile host only in 246 selective routers and base stations. 248 The approximate location information can be represented by a set of 249 base stations called the Paging Area (PA). We do not assume any 250 specific way of defining PAs. Our goal is to support fixed, 251 hierarchical, and even personalized PAs. In order to efficiently 252 search the PA for the mobile host, we exploit the use of IP multicast 253 routing protocol for distributing paging request to a set of base 254 stations. 256 In order to manage router and link failures gracefully, we use 257 soft-state mechanisms for maintaining paging state. We now 258 illustrate the basic mechanism for paging using a simple tree-based 259 topology for the case when packets arrive at the domain root router 260 from some external host for a mobile host that is in standby state. 262 Selected routing and paging entries denoted by the letters R and P 263 are shown adjacent to the routers in Figure 1. These entries are 264 prepended with a message number label indicating which message was 265 responsible for establishing the entry. The letters A,B, and C 266 denote the different interfaces. Let us assume that the mobile host 267 powered up at the old base station and established routing and paging 268 entries as denoted by label (0). Also, let the paging area be 269 configured to consist of the two base stations, OLD BS and NEW BS, 270 assigned to a multicast group address (MGA) of 239.0.0.1. The 271 multicast routing protocols would build a multicast tree with the OLD 272 BS and NEW BS as the leafs and Router 1 as a node in the tree (the 273 corresponding multicast routing entries are shown with a suffix M in 274 the figure). At this time, packets arriving for the mobile host at 275 router 0 will get delivered to the mobile host through the OLD BS 276 using the routing entries just established. 278 | @ 279 (0)R,P:1.1.1.1->B,239.0.0.1 | @ 2 280 (1)P :1.1.1.1->B,239.0.0.1 ------v-- 281 | A | 282 | | 283 | B | 284 --------- ROUTER 0 285 | @ 286 | @ 2 287 | @ 288 ------v-- ROUTER 1 289 (0)M :239.0.0.1->B,C | A | 290 (0)R,P:1.1.1.1->B,239.0.0.1 | | (5)R,P:1.1.1.1->C,239.0.0.1 291 (1)P :1.1.1.1->B,239.0.0.1 | B C | 292 ---------<$$$$$$$ 293 * / @ \ * $ 294 3 * / @ \ * 3 $ 5 295 OLD BS * / 6 @ \ * $ NEW BS 296 --v-- @ --v-- 297 (0)M:239.0.0.1->A / A \ @ / A \ (0)M:239.0.0.1->A 298 (0)R,P:1.1.1.1->B, | | @ | | (0)R:Default->A 299 239.0.0.1 \ B / @ \ B / (4)R,P:1.1.1.1->B, 300 (1)P :1.1.1.1->B, ----- @ $$>----- 239.0.0.1 301 239.0.0.1 * @ $ 4 * 302 3 * * * @ $ * * * 3 303 * * * * * @ $ * * * * * 304 -v-- 305 M:Multicast entry MOBILE / \ @: data packets 306 R:Routing entry HOST \ / *: page request 307 P:Paging entry ---- $: page response 308 IP:1.1.1.1 310 Figure 1: Illustration of paging in HAWAII 312 Now, let label (1) denote the timeout event where the mobile host and 313 the routers in the network enter the standby state because of lack of 314 refreshes from the mobile host. At this time, the routing entries 315 for the mobile host are timed out in the routers and the base 316 stations and only the paging entries remain. Furthermore, let the 317 mobile host now move to NEW BS. Note that the network is unaware of 318 this movement since the host is in standby state. 320 Consider data packets arriving for the mobile host at router 0 (label 321 2). Router 0 would look up its HAWAII entries and find that a paging 322 entry exists for the host. Since the router does not have any 323 entries for MGA 239.0.0.1, it simply forwards the packet along 324 interface B to Router 1. Router 1 looks up the paging entry for the 325 mobile host and finds that the MGA 239.0.01 multicast routing entry 326 exists and has two interfaces associated with it. Assuming that 327 Router 1 is lightly loaded, it buffers the data packets for the 328 mobile host and initiates a paging request (label 3). 330 The mobile host responds to the paging request to the new base 331 station (label 4) which adds routing and paging entries for the host 332 and sends a paging response to the initiator of paging request, 333 Router 1. On receiving message 5, Router 1 updates its routing and 334 paging entries for the host. It then forwards the buffered data 335 packets to the mobile host (label 6). 337 Note that Router 0 would only be updated later by a paging refresh 338 message from Router 1 (until then it will continue forwarding packets 339 for the mobile host correctly to Router 0 since it is not part of the 340 multicast tree for MGA 239.0.0.1). 342 2.4.1 State Synchronization 344 As mentioned earlier, the mobile host operates in two states, active 345 and standby. This can be modeled by a state machine with three 346 states: active, standby and null, with null representing a powered 347 off mobile host. Base stations and routers in the access network 348 need to implement an analogous state machine so that the mobile host 349 is paged in standby state and packets are delivered directly to the 350 mobile host in active state. The state of the network must reflect 351 the state of the mobile host. If the mobile host is in standby 352 state, the state of the mobile host in the network also needs to be 353 in standby state so that paging can be initiated; otherwise, if the 354 mobile host's state in the base station/routers is in active state, 355 the mobile host will not be paged, which may result in packets being 356 misrouted to the wrong base station. Note that, even if the network 357 is in standby state with respect to a mobile host that is in active 358 state, packets will still get delivered correctly; however, this 359 would result in an unnecessary page. 361 Thus, we would like the network to go into standby state for the 362 mobile host exactly when, or just before, the mobile host goes into 363 standby state. Similarly, it is preferable for the network to go 364 into null state only after the mobile host goes into null state. 365 Although this synchronization is not tight, it guarantees that the 366 mobile host will be reachable as long as it is powered up. 368 Table 1: Router operation 369 ----------------------------------------------------------------- 370 Routing Paging State Operation 371 entry entry 372 ----------------------------------------------------------------- 373 Yes Yes Active Regular forwarding 374 Yes No Active No paging support (basic HAWAII) 375 No Yes Standby Paging processing (details: see Figure 5) 376 No No Null Forward if default route exists, else drop 377 ----------------------------------------------------------------- 379 We distinguish two types of entries in the network components such as 380 base stations/routers for maintaining the mobile host's state 381 machine: a routing entry and a paging entry. The operation of the 382 router or base station with respect to these entries is shown in 383 Table 1. 385 2.4.2 Application of IP Multicasting Protocol 387 We need to maintain the current PA for each mobile host and 388 distribute paging requests to the base stations in the PA. Instead of 389 unicasting the paging request to the set of base stations in the PA, 390 IP multicast is used to distribute the paging request. Thus, each PA 391 in a given domain is configured with a multicast group address and 392 each base station in a given PA joins that multicast group. Since 393 the multicast group is within the HAWAII domain, we use the range of 394 addresses that are allocated for administratively scoped IP 395 Multicast [2]. 397 Fixed or hierarchical PAs can be statically configured with different 398 multicast group addresses. In order to support user-defined paging 399 areas, base stations may have to join multicast groups in a dynamic 400 fashion. This is a subject for further study. 402 2.4.3 Distributed Paging 404 The HAWAII paging entry for each mobile host is maintained at a base 405 station and each router on the path from the base station to the 406 Domain Root Router. Every router/base station is capable of 407 initiating paging by buffering incoming packets and sending a paging 408 request to the multicast group. However, the paging processing rules 409 (discussed later) ensure that only one node in the network initiates 410 paging for a particular mobile host at a given time. We also ensure 411 that paging is initiated from routers with the up-to-date paging 412 entries for the mobile host by enforcing that paging is initiated 413 only if packets arrives from the interface to the DRR. In order to 414 push the paging load further down towards the base stations, the 415 router that has multiple interfaces for the PA's MGA initiates the 416 paging. If no such router exists, the packet will eventually reach a 417 base station, which will then assume the paging responsibility. 419 2.4.4 Soft-State 421 The notion of ``soft-state'' refers to state established within 422 routers that needs to be periodically refreshed; otherwise, it is 423 removed automatically when a preset timer associated with that state 424 expires. In addition to maintain routing information as soft state, 425 the HAWAII paging entries within the routers are also maintained as 426 soft-state. This increases the robustness of the protocol to router 427 and link failures. 429 Our protocol uses four types of control messages: requests, 430 responses, updates, and refreshes, to query, establish and maintain 431 the paging soft-state. Paging request messages are triggered inside 432 the network for locating the mobile user, which then responds with a 433 paging response. Paging updates are sent by the mobile host during 434 the crossing of a paging area in standby state. These messages are 435 explicitly acknowledged by the recipient. Paging refresh messages 436 are sent periodically by mobile hosts. Aggregate paging refresh 437 messages are sent periodically by base stations and routers in a 438 hop-by-hop manner to the router upstream of the mobile hosts. As we 439 shall see in the following sections, paging messages are sent to only 440 selected routers in the domain, resulting in very little overhead 441 associated with maintaining soft-state. 443 2.4.5 Stale Paging Entry 445 The protocol ensures that the latest (up-to-date) paging entries are 446 maintained along the path from the DRR to one base station in the PA. 447 Thus, packets arriving for the mobile host from outside the domain 448 will be correctly delivered. However, stale paging entries may exist 449 in internal routers for several reasons such as outdated refresh 450 messages, topology or routing changes, etc. In order to avoid paging 451 using stale paging entries for packets originating inside the domain 452 and destined for a mobile host in standby state, these packets will 453 first be forwarded along the default route to the DRR. The DRR always 454 has the latest paging entry and forwards the packet along the path to 455 a base station. These packets will then trigger paging from a router 456 with the latest paging entry and deliver it to the mobile host. 458 2.5 Protocol Correctness 460 Our paging protocol maintains the following invariants. 462 1. Latest paging entries are maintained for each mobile host along 463 the path from DRR to one base station in PA. 465 2. Paging is initiated from routers with paging entry for the 466 mobile host only if packets arrive from the interface to the 467 DRR. 469 3. Response to a paging request is sent to the paging initiator in 470 a hop-by-hop manner from the mobile host's current base station. 471 This sets up routing and paging entries along the path from the 472 mobile host to the paging initiator. 474 4. State of the base station/routers with the mobile host is 475 ``synchronized'' in the sense that its routing entries time out 476 before a mobile host goes into standby and its paging entries 477 exist as long as the mobile host is not powered off. 479 These invariants guarantee the correctness of the paging protocol. 480 Invariant 4 ensures that a mobile host's paging entry and not its 481 routing entry is used when the mobile host is in the standby state. 482 Invariants 1 and 2 imply that the router/ base station initiating the 483 paging has the latest (up-to-date) paging entry. Invariant 3 484 guarantees that the routing path is set up after paging for packet 485 delivery to the mobile host. 487 3 Detailed Protocol Operation 489 In this section, we describe the protocol processing details of 490 paging for HAWAII. We assume that the HAWAII update message (type 1) 491 is extended to include the multicast group address (MGA) 492 corresponding to the PA. We now describe four new message types and 493 their respective formats in the HAWAII protocol corresponding to the 494 paging request, update, response, and refresh messages. We then 495 present the processing at the mobile host and finally, the protocol 496 processing at the base stations/routers. 498 3.1 Message Formats 500 The format for the paging request is shown below. It is initiated by 501 a router or base station satisfying invariant 2 in Section 2.5. 503 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 |Version| Type | Seq No | Scheme + 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Mobile Host Address | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Paging Initiator Address | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Extensions ... 512 +-+-+-+-+-+-+-+- 514 Version 1 515 Type 5 (paging request) 516 Scheme 1 (fixed PA) 517 Seq No Sequence number of paging request 518 Mobile host Address Home address or Care-of address 519 Paging Initiator Address Router/base station initiating paging 521 The format of paging update and response messages sent by base 522 station/routers is shown next. Paging updates (type 6) are sent 523 hop-by-hop to the DRR when the mobile host crosses a paging area. 524 Paging responses (type 7) are sent hop-by-hop to the initiator of the 525 paging request in response. 527 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |Version| Type | Reason | Scheme + 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Mobile Host Address | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Metric | Routing Lifetime | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Old Base Station | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | New Base Station | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | MGA for current PA | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 + Timestamp + 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Extensions ... 546 +-+-+-+-+-+-+-+- 548 Version 1 549 Type 6 (paging update), 7 (paging response) 550 Scheme 1 (fixed PA) 551 Mobile host Address Home address or Care-of address 552 Metric Distance to the mobile host in hops 553 Routing Lifetime Soft state timer value 554 Old Base Station Old Base Station IP address for Type 2 555 0.0.0.0 for Type 1 (power up) 556 MGA for current PA intra-domain MGA for host's current PA 557 Timestamp Timestamp formatted as in 558 Network Time Protocol [3]. 559 Extensions Authentication field 560 Wireless link specific fields, for study 562 The format for a paging refresh message is shown next. The message 563 could contain multiple entries as part of an aggregate refresh when 564 sent by base stations and routers to their upstream router. The 565 maximum message size is constrained to 4KB. 567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |Version| Type | Reason | Size + 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Mobile Host Address[1] | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | MGA[1] | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 + Timestamp[1] + 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 ... 580 ... 581 ... 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Mobile Host Address[N] | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | MGA[N] | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 + Timestamp[N] + 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Extensions ... 592 +-+-+-+-+-+-+-+- 594 Version 1 595 Type 8 (paging refresh) 596 Size Number of mobile host entries 597 Reason 0 (normal) 598 1 (triggered refresh due to failure) 599 Mobile host Address Host-entry address 600 Timestamp Host-entry timestamp 601 Extensions Authentication field 603 3.2 Mobile Host Processing 605 Figure 2 shows the state diagram at the mobile host for maintaining 606 the ACTIVE, STANDBY, and NULL states. The mobile host can transmit 607 and receive data only in ACTIVE state. In order to transit into 608 ACTIVE state, either the mobile host sends a regular HAWAII 609 registration or the mobile host responds to a paging request. While 610 in ACTIVE state, the mobile host sends HAWAII registrations at least 611 once every Tactive time units. The mobile host goes into STANDBY 612 from ACTIVE state when the mobile host is idle for time Tactive. 613 While in STANDBY state, the mobile hosts sends paging refresh 614 messages at least once every Tstandby time units or paging update 615 messages when it crosses a PA. 617 Startup: send 618 ++++++++ power up update ++++++++ ____ Timeout: 619 + +---------------> + +/ | resend power up 620 + NULL0 + + NULL1 + | update 621 + + <---------------+ + <--/ 622 ++++++++ Give up resends ++++++++ 623 Power ^ ----------------------| | ^ 624 down | | Get ack | | 625 | | w/ active Get ack | | Crossing PA: 626 Every | | w/ standby | | send paging update 627 Tactive, | | | | 628 send routing| v Idle for v | 629 refresh +++++++++ time Tactive ++++++++++ ____ Every 630 |----\+ +---------------> + +/ | Tstandby, 631 | + ACTIVE + + STANDBY + | send paging 632 \--> + + <---------------+ + <--/ refresh 633 +++++++++ Paging response ++++++++++ 634 or routing update 636 Figure 2: Client State Diagram 638 Thus two timers, Tactive and Tstandby, control the idle time for 639 transitions between the ACTIVE to STANDBY and STANDBY to NULL states 640 respectively. These timers will be configured based on usage 641 patterns and battery power consumption statistics for wide-area 642 wireless data devices. Default values for these timers in HAWAII are 643 30 seconds and 30 minutes respectively. 645 3.3 Base Station/Router Processing 647 The processing of power up update message is similar to processing 648 basic HAWAII power up update message in [5]. While basic HAWAII 649 power up update messages establish only routing entries, in this 650 case, we extend it so that both routing and paging entries with the 651 multicast group address (MGA) are established. 653 The pseudo-code for processing paging update message is shown in 654 Figure 3. Paging update messages are sent along the ``default'' 655 route. They are sent when the mobile host crosses a PA. The 656 processing is similar to the processing of a power up update message. 657 The only difference is that this message only sets up paging entries. 658 Note that the notation of the paging entry is similar to the one used 659 in explaining Figure 1. It consists of the mobile host address (MH 660 IP ADDRESS), the multicast group address (MGA), and the forwarding 661 interface. 663 -------------------------------------------------------------------- 664 Figure 3: HAWAII paging update message processing 665 -------------------------------------------------------------------- 666 1. Receive the message from neighbor on Interface A 667 Message contains {MH IP ADDRESS,MGA, TIMESTAMP} 668 2. If TIMESTAMP is greater than current paging entry timestamp then 669 3. If I am the Domain Root Router 670 Add/Update paging entry to be 671 (MH IP ADDRESS -> MGA, Interface A) 672 set timer Tstandby 673 Generate an acknowledgement 674 else 675 Add/Update paging entry to be 676 (MH IP ADDRESS -> MGA, Interface A) 677 set timer Tstandby 678 Forward paging update to upstream neighbor along default route 679 endif 680 endif 681 -------------------------------------------------------------------- 683 The pseudo-code for packet forwarding in HAWAII with paging support 684 is shown in Figure 4. As in basic HAWAII, if a routing entry exists, 685 packets are forwarded using the entry. If the routing entry does not 686 exist but a paging entry exists, paging is initiated only when the 687 packet arrives on the interface from the DRR and the node has not 688 received a refresh from its downstream neighbor due to failure or the 689 node is a lightly loaded router such that outstanding page requests 690 are below a threshold value T or the node is a base station. 691 Otherwise it is forwarded to the DRR. This helps push the burden of 692 paging towards the base station, thereby reducing the load at the 693 DRR. 695 -------------------------------------------------------------------- 696 Figure 4: HAWAII packet forwarding processing in the BS and router 697 -------------------------------------------------------------------- 698 If (there is no routing entry for MH IP address) 699 If (paging table has an entry for MH) // has paging entry 700 Entry contains {MH IP address -> MGA, Interface A} 701 Let Interface B be the interface of the default route 702 if (packet is from Interface B or I am the Domain root Router) 703 if ((no refresh on Interface A) /* Failure */ 704 or (outstanding page requests < T)/*lightly loaded?*/ 705 or (I am a base station)) /* Initiate Paging */ 706 buffer the packet 707 send a paging request message to the MGA 708 increase the retry counter and set timer for paging retry 709 else 710 route the packet to interface A 711 endif 712 else 713 forward the packet along the default route to DRR 714 endif 715 else // no routing or paging entries 716 If (I am not the Domain Root Router) 717 forward the packet along the default route to DRR 718 else 719 discard the packet 720 endif 721 endif 722 else // has routing entry 723 route the packet using the routing entry 724 endif 725 -------------------------------------------------------------------- 727 The pseudo-code for processing a paging response message is shown in 728 Figure 5. The paging response is sent to the initiator of the paging 729 request. It is sent hop-by-hop and routing entries are set up along 730 the way. 732 -------------------------------------------------------------------- 733 Figure 5: HAWAII paging response processing for fixed paging area 734 -------------------------------------------------------------------- 735 1. Receive the message from neighbor on Interface A 736 Message contains {MH IP ADDRESS,MGA, TIMESTAMP} 737 2. If TIMESTAMP is greater than current paging entry timestamp then 738 3. If I am the paging initiator 739 Look up pending paging response for this MH 740 Add/Update routing entry to be {MH IP ADDRESS -> Interface A}, 741 set timer Tactive 742 Generate an acknowledgement 743 else 744 Add/Update routing entry to be {MH IP ADDRESS -> Interface A} 745 set timer Tactive 746 Forward the paging response packet towards paging initiator 747 endif 748 endif 749 -------------------------------------------------------------------- 751 The soft-state paging refresh messages are sent independently by each 752 of the nodes on a hop by hop basis. The mobile host refreshes the 753 base station at least every Tstandby seconds in the STANDBY state. 754 The base stations and routers send HAWAII routing and paging 755 refreshes to their upstream routers (determined based on their 756 default route to the domain root router) every TR1 and TR2 seconds 757 respectively. We require that TR1 and TR2 be more frequent than 758 Tactive and Tstandby in order for the protocol to be robust across 759 message losses. Also, typically Tstandby would be much longer than 760 TR2 in order to conserve the limited wireless bandwidth. When the 761 refresh message is received, the expiry timer corresponding to the 762 refresh entry is updated. The processing of the paging refresh 763 message is very similar to the processing of the routing refresh 764 message in HAWAII [5]. 766 4 Design Implications 768 In this section, we illustrate the advantages of our protocol for 769 paging by studying the implications on scalability, ease of network 770 management and reliability. 772 4.1 Scalability 774 Paging entries for a given mobile host are only present along one 775 path from a base station to the DRR. The closer a router is to the 776 DRR, more paging entries and more refresh/update messages it will 777 process. On the other hand, the farther a router is from the DRR, 778 the probability of paging being initiated is higher. This is because 779 of the rule that the router initiating a paging should be on the 780 multicast tree for the given paging area and have at least two 781 branches; since paging areas are typically localized, such a router 782 would be closer to the paging area and farther from the DRR. Thus, 783 the protocol distributes the processing load due to paging among the 784 different routers in the domain. Given that HAWAII is shown to be 785 scalable in [5] for large-sized domains, we believe that the addition 786 of paging functionality will not impact the scalability of HAWAII 787 adversely. 789 4.2 Ease of Network Management 791 In today's cellular network, every update with respect to location 792 management needs to be propagated to the Mobile Switching Center 793 (MSC) or the Serving GPRS Service Node (SGSN). In HAWAII, if a new 794 base station is installed due to a cell split, the base station just 795 creates/joins the appropriate multicast group. If the base station 796 changes to use a different algorithm to determine the PA, the base 797 station can just regroup into different PAs, and then join the 798 corresponding multicast groups. These changes are transparent to 799 other routers in the domain; the multicast routing protocol will 800 automatically compute the new multicast tree for each of the PAs. 801 Furthermore, by having a pure IP-based solution for mobility 802 management, the routers in the wireless access network are shielded 803 from details specific to the wireless interface. On the other hand, 804 the use of specialized components such as the MSCs or the SGSNs for 805 each wireless link protocols implies that each of these components 806 must be managed in a separate manner, thereby increasing the cost and 807 complexity of deployment. 809 4.3 Reliability 811 Paging can be initiated by any router/base station along the path to 812 the DRR. Therefore unlike a centralized approach, there is no single 813 point of failure with respect to paging. 815 Link and router failures are handled through the soft-state refresh 816 mechanism in HAWAII. The HAWAII daemon running at each router would 817 detect these failures and update its default route/paging entry. 818 This will trigger an immediate soft-state routing and paging refresh 819 messages for all its host entries to a new uplink router. This will 820 result in further propagation of soft-state refresh messages until a 821 router that has pre-existing entries for the affected mobile hosts is 822 notified (this will be the domain root router in the worst case). 824 5 Paging with Mobile-IP 826 So far, we considered how paging support can be added to HAWAII. 827 Paging support can also be added to basic Mobile-IP using a similar 828 approach. However, some of the scalability and reliability 829 advantages of paging with HAWAII may no longer be possible. 831 5.1 HA paging 833 HA paging is performed in a centralized manner at the home agent. 834 When a mobile host registers with its home agent, it sends the 835 identity of its current PA. When a packet destined for a mobile host 836 in standby state arrives at the HA, the HA buffers the packet and 837 contacts all the base stations in the PA. The base stations 838 subsequently page over the air. The mobile host then registers its 839 current location with the HA, which delivers the buffered packet as 840 well as subsequent packets. 842 One drawback with this approach is that the HA needs to be informed 843 of the addresses of the base stations in the PA. Since the base 844 stations and the HA can belong to different administrative domains, 845 the PA information could be considered confidential and may not be 846 available. The use of globally visible multicast group address to 847 represent the PA is one possible solution but global multicast has 848 its own scalability concerns. 850 The HA paging approach is similar to the centralized paging 851 implementations in current wide-area cellular networks; in GPRS, 852 paging is performed at the Serving GPRS Service Node (SGSN), while in 853 CDMA, it is implemented at the Mobile Switching Center (MSC). The 854 main difference is that cellular paging is always performed inside 855 the visiting network rather than from the home network as in HA 856 paging, thus avoiding the confidentiality issues of HA paging. 858 5.2 FA paging 860 In FA paging, paging is initiated at the mobile host's last attached 861 FA (base station). When a packet destined for a mobile host in 862 standby state arrives at the HA, the HA tunnels the packet to the FA 863 as in basic Mobile IP. Thus, the HA is unaware of the fact that the 864 mobile host is in standby state and needs to be paged. The FA 865 buffers the packet and multicasts a page message to the base stations 866 in the PA. The base stations subsequently page over the air. The 867 mobile host then registers its new location (FA) with the HA and also 868 simultaneously informs the previous FA so that the buffered packet 869 can be forwarded. If the mobile host happened to remain at its 870 previous base station, the latter two messages are avoided. 872 One issue with this approach that needs to be addressed is the impact 873 of foreign agent failures. In HA paging, HA failure would leave the 874 mobile host disconnected. In FA paging, in addition, even in the 875 presence of an end-to-end path to the mobile host, the failure of the 876 previous foreign agent could result in the mobile host being 877 unreachable indefinitely (since the previous FA is the paging 878 initiator). One way to avoid this is to allow the HA to monitor the 879 different FA's in the paging area but then this rises confidentiality 880 concerns; therefore, some form of failure recovery protocol amongst 881 the different FA's in a PA need to be implemented. 883 6 Security 885 This protocol has been defined as an extension to the HAWAII 886 protocol [5]. The security model of the HAWAII protocol directly 887 applies for the messages from the mobile host. Regarding the paging 888 messages which are generated and processed only from within a given 889 administrative domain, simple mechanisms such as password protection 890 should suffice. 892 References 894 [1] Digital cellular telecommunication system, General Packet Radio 895 Service, Service description - Stage 2, GSM 03.60 Version 6.0, 896 ETSI, 1998. 898 [2] D. Meyer, ``Administratively Scoped IP Multicast,'' Request for 899 Comment 2365, July 1998. 901 [3] D. Mills, "Network Time Protocol (Version 3): Specification, 902 Implementation and Analysis", RFC 1305, Mar 1992. 904 [4] C.E. Perkins, ``IP Mobility Support,'' Request for Comments 2002, 905 Oct 1996. 907 [5] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli, 908 ``IP micro-mobility support using HAWAII,'' Internet Draft, Work 909 in Progress, June 1999. 911 [6] A. Valko, A. Campbell, and J. Gomez, ``Cellular IP,'' Internet 912 Draft, Work in Progress, November 1998. 914 Authors' Addresses 916 R. Ramjee, T. La Porta 917 Bell Labs, Lucent Technologies, 918 101 Crawfords Corner Road, 919 Holmdel, NJ 07733 (USA) 920 Phone: 732-949-3306 921 Fax: 732-949-4513 922 Email: {ramjee,tlp}@bell-labs.com 924 L. Li 925 Department of Computer Science, 926 Cornell University 927 Email: lili@cs.cornell.edu