idnits 2.17.1 draft-ramjee-micro-mobility-hawaii-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 202 has weird spacing: '...located domai...' == Line 583 has weird spacing: '...resends hand...' -- 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 (19 February 1999) is 9197 days in the past. Is this intentional? -- 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 540 == Missing Reference: '0' is mentioned on line 796, but not defined -- Looks like a reference, but probably isn't: '2pi' on line 796 == Unused Reference: '4' is defined on line 1084, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1723 (ref. '3') (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2002 (ref. '6') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2138 (ref. '7') (Obsoleted by RFC 2865) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999 2 Internet Engineering Task Force R. Ramjee / T. La Porta 3 INTERNET-DRAFT S. Thuel / K. Varadhan 4 draft-ramjee-micro-mobility-hawaii-00.txt Lucent Bell Labs 5 19 February 1999 6 Expires: 19 August 1999 8 IP micro-mobility support using HAWAII 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 In this contribution, we present HAWAII: a domain-based approach for 34 supporting mobility. HAWAII uses specialized path setup schemes 35 which install host-based forwarding entries in specific routers to 36 support intra-domain micro-mobility and defaults to using Mobile-IP 37 for inter-domain macro-mobility. These path setup schemes deliver 38 excellent performance by reducing mobility related disruption to user 39 applications, and by operating locally, reduce the number of mobility 40 related updates. Also, in HAWAII, mobile hosts retain their network 41 address while moving within the domain, simplifying Quality of 42 Service support. Furthermore, reliability is achieved through the 43 use of soft-state forwarding entries for the mobile hosts, and the 44 elimination of foreign agents and, in some cases, the home agent. 46 Contents 48 1 Introduction 3 49 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.4 Design Overview . . . . . . . . . . . . . . . . . . . . . . 4 53 1.4.1 Network Architecture . . . . . . . . . . . . . . . . . 5 54 1.4.2 Path Setup Schemes . . . . . . . . . . . . . . . . . . 6 55 1.4.3 Soft-State . . . . . . . . . . . . . . . . . . . . . . 7 57 2 Path Setup Schemes 7 58 2.1 Forwarding Path Setup Scheme . . . . . . . . . . . . . . . 8 59 2.2 Non-Forwarding Path Setup Scheme . . . . . . . . . . . . . . 10 61 3 Protocol Processing 11 62 3.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . 11 63 3.2 Mobile Host Processing . . . . . . . . . . . . . . . . . . . 13 64 3.3 Base Station/Router Processing . . . . . . . . . . . . . . . 15 66 4 Design Implications 17 67 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 18 68 4.2 Quality of Service Support . . . . . . . . . . . . . . . . . 19 69 4.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 22 71 5 Address Assignment 22 73 6 Security 23 74 1 Introduction 76 Mobile-IP is the current standard for supporting macro-mobility in IP 77 networks [6]. Mobile-IP defines two entities to provide mobility 78 support: a home agent (HA) and a foreign agent (FA). The HA is 79 statically assigned to a mobile host based on the permanent home IP 80 address of the mobile host. The FA is assigned to the mobile host 81 based on its current location. The FA has associated with it an IP 82 address called the care-of address. Packets sent to the mobile host 83 are intercepted by the HA and tunneled to the FA at the care-of 84 address. The FA then decapsulates the packets and forwards them 85 directly to the mobile host. Thus, Mobile-IP provides a good 86 framework for allowing users to roam outside their home networks. 87 When Mobile-IP is used for micro-mobility support, it results in high 88 control overhead due to frequent notifications to the HA. Also, in 89 the case of a Quality of Service (QoS) enabled mobile host, acquiring 90 a new care-of address on every handoff would trigger the 91 establishment of new QoS reservations from the HA to the FA even 92 though most of the path remains unchanged. Thus, while Mobile-IP 93 should be the basis for mobility management in wide-area wireless 94 data networks, it has several limitations when applied to wide-area 95 wireless networks with high mobility users that may require QoS. Our 96 aim is to extend Mobile IP to address these limitations using 97 Handoff-Aware Wireless Access Internet Infrastructure (HAWAII). 99 1.1 Goals 101 We have three design goals: 103 o Achieve good performance by reducing update traffic to home 104 agent and corresponding hosts, avoiding triangular routing where 105 possible, and limiting disruption to user traffic. 106 o Provide intrinsic support for QoS in the mobility management 107 solution, including allowing per flow QoS and limiting the 108 number of reservations that must be re-established when hosts 109 move. 110 o Enhance reliability. We require HAWAII to be no less fault 111 tolerant than existing Mobile-IP proposals, and we explore 112 additional mechanisms to improve the robustness of mobility 113 support. 115 1.2 Assumptions 117 Our proposal for supporting mobility hinges on the assumption that 118 most user mobility is local to a domain, in particular, an 119 administrative domain of the network. Since an administrative domain 120 is under the control of a single authority, it is possible to relax 121 the assumption that there is no special support for mobility 122 available in the domain infrastructure. Therefore, we consider 123 optimizations in routing and forwarding in the domain routers for 124 more efficient support of intra-domain mobility. 126 1.3 Terminology 128 Domain 130 A division of the wireless access network. It consists of one or 131 more routers and multiple base stations. It will appear as a 132 subnet to routers external to the domain. 134 Domain Root Router 136 The gateway router into a domain is called the domain root router. 138 Home Domain 140 Each mobile host is assigned a home domain based on its permanent 141 IP address. 143 Foreign Domain 145 Any domain that is not the mobile host's home domain is referred 146 to as its foreign domain. 148 Path Setup Scheme 150 A particular method of updating the routers in a domain so that 151 connectivity to the mobile host is maintained across handoffs. 153 1.4 Design Overview 155 In this section, we present the architecture of HAWAII. There are 156 three separate components to HAWAII: 1) To achieve maximum 157 transparency in mobility, we consider a two-level hierarchy along 158 domain boundaries, and define separate mechanisms for intra-domain 159 mobility and inter-domain mobility. We conjecture that mobility 160 across domains is likely to be a rare occurrence and default to using 161 Mobile-IP for inter-domain mobility. To provide straight-forward QoS 162 support, we assign a unique, co-located care-of address to the mobile 163 host; 2) To maintain end-to-end connectivity with little disruption 164 as the mobile host moves, we establish special paths to the mobile 165 host; and finally, 3) To provide a degree of tolerance to router or 166 link failures within the network, we use soft-state mechanisms for 167 maintaining forwarding state. We discuss each of these issues 168 separately in the following sections. 170 1.4.1 Network Architecture 172 ___ ___ 173 | | Internet | | 174 | | Core | | 175 |___| |___| 176 x\ / 177 x\ / 178 x\ ____/ 179 x| | Regular IP Packets xxxxx 180 x | Encapsulated IP Packets @@@@@ 181 |x___| Domain Boundaries ***** 182 x /\ 183 ********************x / \************************* 184 * x /* *\ * 185 * Home x / ** \ Foreign * 186 * Domain _x_/ * \ ___ Domain * 187 * Root --->|x@@@@@@@@@@@@@@@ |<--Root * 188 * Router |x | * | @ | Router * 189 * |x__| * |_@_| * 190 * Home Domain x * @ Foreign Domain * 191 * x x x * @@@ * 192 * x x x * @ @ @ * 193 * x x x * @ @ @ * 194 * x x x * @ @ @ * 195 * x x x * @ @ @ * 196 * ___ x * ___ * 197 * | | * | | Mobile * 198 * | | * | | Host * 199 * |___|----->------->--*--->----->--->|___| * 200 * * * 201 * Movement Movement across domains Movement within * 202 * within domain (HA notified of co-located domain (no HA * 203 * (no HA involved) care-of address) notification) * 205 Figure 1: Hierarchy 207 A common approach for providing transparent mobility to correspondent 208 hosts is to divide the network into hierarchies. In HAWAII we define 209 a hierarchy based on domains. The network architecture is 210 illustrated in Figure 1. The gateway into each domain is called the 211 domain root router. Each host has an IP address and a home domain. 212 For the moment, we defer the discussion of how this address could be 213 assigned later (Section 5). When moving in its home domain, the 214 mobile host retains its IP address. Packets destined to the mobile 215 host reach the domain root router based on the subnet address of the 216 domain and are then forwarded over special dynamically established 217 paths to the mobile host. This allows the home domain to cover a 218 large area made up of hundreds of base stations, thereby increasing 219 the probability that a mobile host is in its home domain. For these 220 mobile hosts, a home agent is not involved in the data path, 221 resulting in enhanced reliability and efficient routing. 223 When the mobile host moves into a foreign domain, we revert to 224 traditional Mobile-IP mechanisms. If the foreign domain is also 225 based on HAWAII, then the mobile host is assigned a co-located 226 care-of address from its foreign domain. Packets are tunneled to the 227 care-of address by a home agent in its home domain. When moving 228 within the foreign domain, the mobile host retains its care-of 229 address unchanged (thus, the HA is not notified of these movements); 230 connectivity is maintained using dynamically established paths in the 231 foreign domain. 233 The design choices of using co-located care-of addresses and 234 maintaining the mobile host address unchanged within a domain 235 simplifies per flow QoS support as discussed in Section 4.2. This 236 choice also eliminates the need for a FA in the domain, thereby 237 enhancing reliability. Also, in Mobile-IPv6 [2], the FA is 238 eliminated and the co-located care-of address option is used. One 239 drawback of using the co-located care-of address option is the need 240 for two IP addresses for each mobile host that is away from its home 241 domain. This exacerbates the limited IP address availability 242 problem. One possible optimization is to adapt the ``dialup'' model 243 used by ISPs to wireless networks. This is discussed in Section 5. 245 1.4.2 Path Setup Schemes 247 As described above, HAWAII assigns a unique address for each mobile 248 host that is retained as long as the mobile host remains within its 249 current domain. In this context, maintaining end-to-end connectivity 250 to the mobile host requires special techniques for managing user 251 mobility. HAWAII uses path setup messages to establish and update 252 host-based routing entries for the mobile hosts in selective routers 253 in the domain so that packets arriving at the domain root router can 254 reach the mobile host. The choice of when, how, and which routers 255 are updated constitutes a particular path setup scheme. In 256 Section 2, we describe two such path setup schemes. 258 One important question in using host-based forwarding in the domain 259 routers is scalability. It is because of scalability considerations 260 that we use Mobile-IP mechanisms for inter-domain mobility. In 261 Section 4.1, we present a numerical example showing how a single 262 domain in HAWAII can cover an area of approximately 1000Km2 without 263 any difficulty in processing mobility related updates. 265 1.4.3 Soft-State 267 The notion of ``soft-state'' refers to state established within 268 routers that needs to be periodically refreshed; otherwise, it is 269 removed automatically when a preset timer associated with that state 270 expires. The HAWAII path state within the routers is soft-state. 271 This increases the robustness of the protocol to router and link 272 failures. 274 Our protocol uses two types of control messages, updates and 275 refreshes, to establish and maintain the soft-state respectively. 276 Path setup updates are sent by the mobile host during power up and 277 following a handoff. These messages are explicitly acknowledged by 278 the recipient. Path setup refresh messages are sent periodically by 279 mobile hosts. Aggregate refresh messages are sent periodically by 280 base stations and routers in a hop-by-hop manner to the router 281 upstream of the mobile hosts. As we shall see in the following 282 sections, path messages are sent to only selected routers in the 283 domain, resulting in very little overhead associated with maintaining 284 soft-state. 286 2 Path Setup Schemes 288 Path setup update messages are sent by the mobile host during power 289 up and following a handoff. We first discuss the update procedure 290 for power up. We then describe two algorithms by which update 291 messages in HAWAII are used to re-establish path state after 292 handoffs. 294 When the mobile host powers up, it sends a path setup update message 295 to its nearest base station. This message propagates to the domain 296 root router. Each router in the path between the mobile host and the 297 domain root router adds a forwarding entry for the mobile host. 298 Finally, the domain root router sends back an acknowledgement to the 299 mobile host. At this time, when packets destined for the mobile host 300 arrive at the domain root router based on the subnet portion of the 301 mobile host's IP address, the packets are routed within the domain to 302 the mobile host using the host-based forwarding entries just 303 established. Note that other routers in the domain have no specific 304 knowledge of this mobile host's IP address. In the case of mobile to 305 mobile communication, packets arriving at a router that has no 306 specific host-based entry are routed using a default route. The 307 packets eventually reach an upstream router (in the worst case, the 308 domain root router) which has a forwarding entry for the mobile host. 310 We now describe the operations of two path setup schemes used to 311 re-establish path state when the mobile host moves from one base 312 station to another within the same domain. We assume a tree-based 313 topology for the discussion although the path setup schemes work with 314 any arbitrary topology. For the remaining subsections, let us define 315 the cross-over router as the router closest to the mobile host that 316 is at the intersection of two paths, one between the domain root 317 router and the old base station, and the second between the old base 318 station and the new base station. In both path setup schemes, 319 forwarding entries during handoff are added so that packets are 320 either forwarded from the old base station or diverted from the 321 cross-over router to the new base station. This property ensures us 322 against the possibility of persistent loops after the handoff update. 324 There are two variants of the path setup schemes, motivated by two 325 types of wireless networks. The Forwarding scheme is optimized for 326 networks where the mobile host is able to listen/transmit to only one 327 base station as in the case of a Time Division Multiple Access (TDMA) 328 network. The Non-Forwarding scheme is optimized for networks where 329 the mobile host is able to listen/transmit to two or more base 330 stations simultaneously for a short duration, as in the case of a 331 WaveLAN or Code Division Multiple Access (CDMA) network. These are 332 described below. 334 2.1 Forwarding Path Setup Scheme 336 In this path setup scheme, packets are first forwarded from the old 337 base station to the new base station before they are diverted at the 338 cross-over router. 340 The Forwarding scheme is illustrated in Figure 2. The forwarding 341 table entries are shown adjacent to the routers. These entries are 342 prepended with a message number indicating which message was 343 responsible for establishing the entry (a message number of zero 344 indicates a pre-existing entry). The letters denote the different 345 interfaces. The path setup message is first sent by the mobile host 346 to the old base station. The message contains the new base station's 347 address. The old base station performs a routing table lookup for 348 the new base station and determines the interface, interface A, and 349 next hop router, Router 1. The base station then adds a forwarding 350 entry for the mobile host's IP address with the outgoing interface 351 set to interface A. It then forwards the message to Router 1 (shown 352 as message 2 in Figure 2). Router 1 performs similar actions and 353 forwards the message to Router 0. Router 0, the cross-over router in 354 this case, adds forwarding entries that result in new packets being 355 diverted to the mobile host at the new base station. It then 356 forwards the message towards the new base station. Eventually the 357 message reaches the new base station (shown as message 5 in Figure 358 2). The new base station changes its forwarding entry and sends an 359 acknowledgement of the path setup message to the mobile host (shown 360 as message 6 in Figure 2). 362 | (0):1.1.1.1->B 363 --------- (3):1.1.1.1->C 364 | A | 365 ROUTER 0 | | 366 | B C | 367 @@@@@>--------- @@@@@ 368 @ / @@@@ \ @ 369 3 @ / @ @ \ @ 4 370 @ / @ @ \ @ 371 @ / @ @ \ v 372 ROUTER 1---------@ @--------- ROUTER 2 373 | A |@ @| A | 374 (0):1.1.1.1->C | |@ @| | (0):Default->A 375 (2):1.1.1.1->A | B C |@ @| B C | (4):1.1.1.1->B 376 ---------@ @--------- 377 ^ | @ @ | @ 378 2 @ | @ @ | @ 5 379 @ | @ @ | @ 380 @ | @ @ | v 381 OLD BS -----<@ @ ----- NEW BS 382 / A \ @ / A \ 383 (0):1.1.1.1->B | | @| | (0):Default->A 384 (1):1.1.1.1->A \ B / @ \ B / (5):1.1.1.1->B 385 ----- 1 @ ----- 386 @ @ 6 387 @ @ 388 ---- <@@@@@ 389 MOBILE / \ 390 USER \ / 391 ---- 392 IP:1.1.1.1 394 Figure 2: Forwarding path setup scheme 396 Note that only the new and old base stations, and the routers 397 connecting them, are involved in processing the path setup message. 398 Also, only routers on the path between the new base station and the 399 domain root router will receive the periodic refresh messages. 400 Therefore, the entries in Router 1 and the old base station, which 401 are no longer on this path, will time-out, while the entries in 402 Routers 0 and 2, and the new base station will get refreshed. 404 2.2 Non-Forwarding Path Setup Scheme 406 | (0):1.1.1.1->B 407 --------- (3):1.1.1.1->C 408 | A | 409 ROUTER 0 | | 410 | B C | 411 @@@@@@---------<@@@@@ 412 @ / @@@@ \ @ 413 4 @ / @ @ \ @ 3 414 @ / @ @ \ @ 415 v / @ @ \ @ 416 ROUTER 1---------@ @--------- ROUTER 2 417 | A |@ @| A | 418 (0):1.1.1.1->C | |@ @| | (0):Default->A 419 (4):1.1.1.1->A | B C |@ @| B C | (2):1.1.1.1->B 420 ---------@ @--------- 421 @ | @ @ | ^ 422 5 @ | @ @ | @ 2 423 @ | @ @ | @ 424 v | @ @ | @ 425 OLD BS ----- @ @ ----- NEW BS 426 / A \ @ / A \ 427 (0):1.1.1.1->B | | @| | (0):Default->A 428 (5):1.1.1.1->A \ B / 6 @ \ B / (1):1.1.1.1->B 429 ----- @ --^-- 430 @@ @ 431 @ @ 1 432 --v- @@@@@@ 433 MOBILE / \ 434 USER \ / 435 ---- 436 IP:1.1.1.1 438 Figure 3: Non-Forwarding path setup scheme 440 In this path setup scheme, as the path setup message travels from the 441 new base station to the old base station, data packets are diverted 442 at the cross-over router to the new base station, resulting in no 443 forwarding of packets from the old base station. 445 The Non-Forwarding scheme is illustrated in Figure 3. In this case, 446 when the new base station receives the path setup message, it adds a 447 forwarding entry for the mobile host's IP address with the outgoing 448 interface set to the interface on which it received this message. It 449 then performs a routing table lookup for the old base station and 450 determines the next hop router, Router 2. The new base station then 451 forwards the path setup message to Router 2 (shown as message 2 in 452 Figure 3). This router performs similar actions and forwards the 453 message to Router 0. At Router 0, the cross-over router in this 454 case, forwarding entries are added such that new packets are diverted 455 directly to the mobile host at the new base station. Eventually the 456 message reaches the old base station (shown as message 5 in Figure 457 3). The old base station changes its forwarding entry and sends an 458 acknowledgement of the path setup message back to the mobile host 459 (shown as message 6 in Figure 3). 461 3 Protocol Processing 463 In this section, we describe the protocol processing details of 464 HAWAII path setup schemes. We first describe the format for the path 465 setup update and refresh messages. We then present the processing at 466 the mobile host and finally, the protocol processing at the base 467 stations/routers. 469 3.1 Message Formats 471 The format of an update path setup message sent by a mobile host is 472 shown below. The message is sent using the UDP protocol to a 473 reserved port. Power up updates (type 1) are sent to the current 474 base station. Handoff updates (type 2) are sent to the old base 475 station in the case of the Forwarding scheme, and to the new base 476 station in the case of the Non-Forwarding scheme. At present, we do 477 not have a power down update as we rely on the time out of the soft 478 state forwarding entries. It is conceivable to define an explicit 479 tear down message to handle this case. 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 |Version| Type | Scheme | Reason + 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Mobile Host Address | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Old Base Station | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | New Base Station | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 + Timestamp + 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Extensions ... 496 +-+-+-+-+-+-+-+- 498 Version 1 499 Type 1 (Power up update), 2 (handoff update), 500 3 (acknowledgement) 501 Scheme 1 (Forwarding), 2 (Non-Forwarding) 502 Reason Used only for Type 3 messages 503 0 accepted 504 1 poorly formatted message 505 2 authentication failed 506 3 Scheme not supported 507 Mobile host Address Home address in Home domain, 508 Care-of address in Foreign domain 509 Old Base Station Old Base Station IP address for Type 2 510 0.0.0.0 for Type 1 511 New Base Station New Base Station IP address for Type 2 512 Current Base Station for Type 1 513 Timestamp Timestamp formatted as in 514 Network Time Protocol [3]. 515 Extensions Authentication field 516 Wireless link specific fields, for more study 518 The format for a refresh message is shown next. The message would 519 contain only one entry when sent by a mobile host and could contain 520 multiple entries as part of an aggregate refresh when sent by base 521 stations and routers to their upstream router. 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 |Version| Type | Size | Reason + 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Mobile Host Address[1] | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 + Timestamp[1] + 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 ... 534 ... 535 ... 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Mobile Host Address[N] | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 + Timestamp[N] + 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Extensions ... 544 +-+-+-+-+-+-+-+- 546 Version 1 547 Type 4 (refresh) 548 Size Number of mobile host entries 549 Reason 0 (normal) 550 1 (triggered due to link/host failure) 551 Mobile host Address Host-entry address 552 Timestamp Host-entry timestamp 553 Extensions Authentication field 555 3.2 Mobile Host Processing 557 The processing requirements for a mobile host depends on whether it 558 is attached to its home domain or a foreign domain. When it is in 559 its home domain, the mobile host executes a HAWAII client process. 560 The operation of the HAWAII client is depicted in Figure 4. 562 When the HAWAII client process begins execution, it reads the host's 563 configuration parameters (such as its IP address) and sends a power 564 up update to the domain root router. It then waits for an 565 acknowledgement in the INIT state. If an acknowledgment is received, 566 the host enters the ATTACHED state, where it can send and receive 567 packets. If an acknowledgment is not received after a certain period 568 of time, the host resends the update message possibly multiple times 569 until it finally receives an acknowledgement or decides to abandon 570 executing the client process. If attachment is successful, the 571 mobile host periodically sends a refresh message to the base station 572 to which it is attached. The base station will, in turn, generate 573 hop-by-hop refresh messages upstream, as described earlier. 575 On startup, send 576 ++++++++ power up update ++++++++ ____ On timeout, 577 + +---------------> + +/ | resend power up 578 + NULL + + INIT + | update 579 + + <---------------+ + <--/ 580 ++++++++ Give up resends ++++++++ 581 ^ | 582 ^ Give up Inter-domain | | Receive ack from 583 | resends handoff, send | | domain root router 584 On timeout, | power up update| | 585 resend | | v 586 updates | Receive ack from | 587 ____ +++++++++ base station ++++++++++ ____ 588 | \+ +---------------> + +/ | Send periodic 589 | + HANDOFF + + ATTACHED + | refreshes 590 \--> + + <---------------+ + <--/ 591 +++++++++ Intra-domain ++++++++++ 592 handoff, send 593 handoff update 595 Figure 4: HAWAII Client State Diagram 597 When the mobile host moves to a new base station, if a domain 598 boundary is crossed, the mobility client is notified that a 599 inter-domain handoff has occurred and it is also informed of the new 600 care-of address. The host then triggers the creation of host-based 601 forwarding entries in the new domain through a power up update. If 602 the mobile host moves to a new base station but does not cross a 603 domain boundary, then the HAWAII client is notified of a intra-domain 604 handoff. It is also informed of the IP address of the new 605 base-station. The client then triggers a handoff update message and 606 moves into the HANDOFF state. If the acknowledgement is received, 607 the host returns to the ATTACHED state. If not, the host continues 608 to send handoff update messages and wait for a reply until it 609 succeeds in getting a reply or decides to abandon executing the 610 client process. 612 There are several ways in which the handoff detection and 613 notification may be implemented. A typical solution is to have the 614 base stations send beacons periodically with their IP address and a 615 domain identifier. A mobile client monitoring these beacons can then 616 detect handoffs and it will have the necessary configuration 617 information for its operation. If it is necessary to interoperate 618 with existing base station beacons which do not contain information 619 regarding IP addresses or domain identifiers, then it is possible to 620 have the mobile client query the base station by sending link layer 621 point to point messages. The details of different query response 622 mechanisms are to be discussed. 624 As stated earlier, there are additional processing requirements when 625 the mobile host is in a foreign domain. The mobile host needs a 626 mechanism for acquiring a care-of address (such as a DHCP client) and 627 a co-located foreign agent as in Mobile-IP [6]. The mobile host must 628 first acquire its care-of address before the HAWAII client sends a 629 power up update in the new domain. After the update processing is 630 completed, the foreign agent will register the care-of address with 631 its home agent. 633 3.3 Base Station/Router Processing 635 The pseudo-code for processing an power up update message in both the 636 Forwarding and Non-forwarding schemes is shown in Figure 5. Each 637 base station simply adds an entry for the mobile host and forwards 638 the message to next hop router along its ``default'' route. Note 639 that we assume that the default route is the same as the route to a 640 domain root router (gateway). When the message reaches a domain root 641 router, an acknowledgement is sent to the mobile host. 643 -------------------------------------------------------------------- 644 Figure 5: HAWAII power up Update processing for both schemes 645 -------------------------------------------------------------------- 646 1. Receive Power Up Update message from mobile host on Interface 1 647 2. Message contains MH IP ADDRESS, TIMESTAMP 648 3. Add/Update entry {MH IP ADDRESS -> Interface 1}, set timer 649 4. If I am the Domain Root Router 650 Generate an acknowledgement back to the MH 651 else 652 Forward update to upstream neighbor along the default route 653 endif 654 -------------------------------------------------------------------- 656 The pseudo-code for processing an update message in the Forwarding 657 and Non-Forwarding schemes is shown in Figure 6(a) and Figure 6(b) 658 respectively. The processing of an update message is fairly simple: 659 on receiving the message, modify the forwarding entry for the mobile 660 host in the kernel and forward the update message towards its 661 destination. 663 -------------------------------------------------------------------- 664 Figure 6(a): HAWAII handoff processing for the Forwarding scheme 665 -------------------------------------------------------------------- 666 1. Receive Update message from neighbor on Interface 1 667 2. Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP 668 3. If NEW BS ADDRESS matches one of my interface addresses then 669 Let Interface 2 be my wireless interface 670 else 671 Look up routing table for NEW BS ADDRESS and determine 672 next hop router and outgoing interface Interface 2 673 endif 674 4. If TIMESTAMP is newer then 675 Add/Update entry {MH IP ADDRESS -> Interface 2}, set timer 676 endif 677 5. If NEW BS ADDRESS matches one of my interface addresses then 678 Generate an acknowledgement back to the MH 679 else 680 Forward message to next hop router determined in step 3 681 endif 682 -------------------------------------------------------------------- 683 Figure 6(b): HAWAII handoff processing for the Non-forwarding scheme 684 -------------------------------------------------------------------- 685 1. Receive Update message from neighbor on Interface 1 686 2. Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP 687 3. If TIMESTAMP is newer then 688 Add/Update entry {MH IP ADDRESS -> Interface 1}, set timer 689 endif 690 4. If OLD BS ADDRESS matches one of my interface addresses then 691 Generate an acknowledgement back to the MH 692 else 693 Look up routing table to find next hop router for OLD BS ADDRESS 694 Forward message to next hop router 695 endif 696 -------------------------------------------------------------------- 698 The soft-state refresh messages are sent independently by each of the 699 nodes on a hop by hop basis. The mobile host refreshes the base 700 station every TH seconds. The base stations and routers send 701 refreshes to their upstream routers (determined based on their 702 default route to the domain root router) every TR seconds. Typically 703 TH would be much larger than TR in order to conserve the limited 704 wireless bandwidth. When the refresh message is received, the expiry 705 timer corresponding to the refresh entry is updated. This involves 706 no update to the kernel routing table and can be done very 707 efficiently. Furthermore, a single refresh message can refresh 708 several mobile hosts, thus amortizing on the cost of 709 sending/receiving the message. The pseudo-code for processing a 710 refresh message is shown in Figure 7. One important point to note is 711 the need for a user-specific timestamp in the path setup messages. 712 The timestamp guards against a potential race-condition involving a 713 soft-state refresh from an old base station competing with a recent 714 update message from a new base station. 716 -------------------------------------------------------------------- 717 Figure 7: HAWAII refresh processing for both schemes 718 -------------------------------------------------------------------- 719 1. Receive Refresh message from authenticated neighbor on Interface 1 720 2. Message contains multiple tuples of {MH IP ADDRESS, TIMESTAMP} 721 3. For each tuple do 722 If entry exists for MH IP ADDRESS then 723 If TIMESTAMP is greater than timestamp in the entry then 724 If entry already has interface as Interface 1 725 /* Most common case - no failure */ 726 reset timer on forwarding entry 727 else 728 /* interface changed failure,don't propagate up */ 729 update entry {MH IP ADDRESS -> Interface 1}, set timer 730 endif 731 endif 732 else 733 /* Non-existent MH entry failure, propagate up */ 734 Add entry {MH IP ADDRESS -> Interface 1}, set timer 735 Send immediate update (batched) using the default route 736 endif 737 4. Periodically send batch refresh upstream for all entries 738 5. When the default route changes 739 send batch refresh upstream for all entries 740 ------------------------------------------------------------------- 742 4 Design Implications 744 In this section, we illustrate the advantages of the HAWAII approach 745 by studying the implications on scalability, QoS support, and 746 reliability. 748 4.1 Scalability 750 In this section, we illustrate the advantages of HAWAII's local 751 mobility through a numerical example. Consider a domain with 752 configuration parameters as shown in Table 1. The domain is in the 753 form of a tree with three levels: at the highest level there is a 754 single domain router; at the second level there are seven 755 intermediate routers; at the third and lowest level, there are 140 756 base stations (twenty per router). We also assume that the coverage 757 area of a base station is a square with a given perimeter. For this 758 configuration, we compute the rate of mobility related messages for 759 two different approaches: 1) Mobile-IP approach where FAs are 760 present at each base station and are served by a HA and 2) the HAWAII 761 approach where the HA is at the domain root router. 763 Table 1: Domain Configuration values 764 -------------------------------------------------------------------- 765 Item Type Value 766 -------------------------------------------------------------------- 767 B Base stations per domain root router 140 768 R Second level router per domain root router=(B/S) 7 769 D User density (active users) 39 per sq km 770 V User speed 112 km/hr 771 TR Router refresh timer for HAWAII 30 seconds 772 Y No. of mobile host entries in refresh in HAWAII 25 773 TM Mobile-IP binding lifetime 300 seconds 774 Z Fraction of users in foreign domain in HAWAII 0.1 775 LB Perimeter of base station 10.6 km 776 A Coverage area of domain = B*LB*LB/16 = 980 sq km 777 LD Perimeter of domain = SquareRoot(A)*4 = 125.2 km 778 LR Perimeter of 2nd level router=SquareRoot(A/R)*4 47.3 km 779 N Number of users in domain = B*D = 38,720 780 -------------------------------------------------------------------- 782 First note that the coverage area of this domain is quite large: 783 A = 980km2. If we need to scale to larger areas, we would use 784 Mobile-IP to handoff between these domains. The number of forwarding 785 entries at the domain root router in the case of the HAWAII approach 786 is the same as the total number of active users in the domain, and is 787 N = 38, 220. This is well within the capability of a modern router. 788 Furthermore, a majority of these entries are completely specified 789 entries of hosts from a particular domain/subnet. In this case, 790 perfect hashing is possible resulting in O(1) memory access for IP 791 route lookup. Thus, route lookup for data forwarding can be done 792 efficiently at the domain routers. 794 We now compute the impact of mobility-related messages for the two 795 approaches. First consider a system based on Mobile-IP. Assuming the 796 direction of user movement is uniformly distributed over [0,2pi] and 797 using a fluid flow mobility model [5], the rate of mobile hosts 798 crossing a boundary of perimeter l at a speed V is given by 799 f(l)=(D*V*l)/(3600*pi). Since user handoffs between any two base 800 stations in the domain generates an update registration at the HA, 801 the number of mobility related updates at the HA from B base stations 802 is f(LB)*B. The rate of registration renewals for N users is N/TM 803 since every renewal period, each user send out one renewal request. 805 Now consider a system based on HAWAII. The domain root router, which 806 houses the home agent, is the most heavily loaded router in this 807 system as it has to process both path setup messages as well as 808 Mobile-IP messages. The rate of Mobile-IP registrations, which occur 809 only when user cross domain boundaries, is f(LD). The rate of 810 Mobile-IP registration renewals, which are sent by only those users 811 that are away from their home domain, is (Z*N)/TM. Path setup updates 812 at the domain root router are generated whenever a user is handed off 813 between base stations attached to two different second level routers. 814 Thus, the rate of path setup updates is f(LR)*R. Path setup refreshes 815 are aggregates, generated for each user. Thus, the rate of path 816 setup refreshes is (Ceiling(N/Y)/TR). 818 Table 2: Frequency of Mobility related messages (per second) 819 -------------------------------------------------------------------- 820 Type HAWAII at Domain Root Router Mobile-IP at Home Agent 821 -------------------------------------------------------------------- 822 HAWAII update 127.8 0 823 HAWAII refresh 51.3 0 824 Mobile-IP registration 48.4 574 825 Mobile-IP renewals 12.7 127.4 826 -------------------------------------------------------------------- 827 Total 240.2 701.4 828 -------------------------------------------------------------------- 830 The frequency of various mobility related messages for the 831 configuration shown in Table 1 is summarized in Table 2. The total 832 number of control messages received by a HA in Mobile-IP (701.4) is 833 almost three times the number of messages received by a domain root 834 router in HAWAII (240.2). 836 4.2 Quality of Service Support 838 The fact that HAWAII maintains the IP address of the mobile host 839 unchanged within a domain even as it moves simplifies the provision 840 of flow-based QoS. In this section, we illustrate the ease with which 841 the well-known resource reservation protocol, RSVP [9], is integrated 842 with HAWAII. 844 ________________ 845 |CORRESPONDENT |--- 846 |HOST AS SENDER | | 847 |________________| ~ 848 IP:2.2.1.1 ~ [1.1.1.1->C]*** 1 849 | * Asynchronous 850 --------- v notification 851 | A | {DEST, PHOP, NHOP} 852 ROUTER 0 | | {(0):2.2.1.1,A,B} 853 | B C | {(7):2.2.1.1,A,C} 854 ------+--<+++++ 855 / @ \ + 856 / @ \ + 7 857 / 2 @ \ + 858 / v \ + 859 ROUTER 1--------- --------- ROUTER 2 860 | A | | A | 861 [1.1.1.1->A] | | | | [1.1.1.1->B] 862 | B C | | B C | 863 --------- --------- {DEST, PHOP, NHOP} 864 | @ | ^ {(2):2.2.1.1,A,-} 865 | 3 @ | + 6 {(6):2.2.1.1,A,B} 866 | @ | + 867 | v | + 868 OLD BS ----- ----- NEW BS 869 / A \ / A \ 870 | | | | 871 [1.1.1.1->A] \ B / \ B / [1.1.1.1->B] 872 ----- 4 @-^-- 873 @@@@@@@ + {DEST, PHOP, NHOP} 874 @ + 5 {(3):1.1.1.1,A,-} 875 --v- ++++++ {(5):1.1.1.1,A,B} 876 MOBILE HOST / \ 877 AS RECEIVER \ / @@@@@> PATH 878 ---- +++++> RESV 879 IP:1.1.1.1 881 Figure 8: RSVP flows when mobile host is a receiver 883 RSVP inherently assumes that hosts have fixed addresses, which is 884 usually not the case for mobile hosts. When using Mobile-IP, the 885 mobile host's home address is fixed, but its care-of-address changes. 886 Since RSVP uses the destination address of the end node, i.e. the 887 mobile host, for identifying a session, one has to redo the resource 888 reservation along the entire path from the correspondent host (or HA) 889 to the mobile host on every handoff of the mobile user. This must be 890 performed even though most of the path is probably unchanged, as 891 handoff is a local phenomenon. This results in increased reservation 892 restoration latency and unnecessary control traffic. 894 In the case of HAWAII, support for QoS is straightforward since a 895 mobile host's address remains unchanged as long as the user remains 896 within a domain. The interaction between HAWAII and RSVP when the 897 mobile host is a receiver is shown in Figure 8. The state in the 898 square braces represents HAWAII forwarding state while the state in 899 the curly braces represents RSVP state. After Router 0 processes a 900 HAWAII path setup update, its RSVP daemon receives a path change 901 notification (PCN) (message 1) using the routing interface for 902 RSVP [8]. In standard RSVP, the router must now wait a time interval 903 before generating the RSVP PATH message to allow the route to 904 stabilize; this time interval is set to two seconds by default. In 905 HAWAII, the RSVP PATH message (message 2) can be triggered 906 immediatedly on receiving a PCN since the route to the mobile host is 907 stable at that point. This allows for a faster reconfiguration due 908 to mobility. The PATH message follows the new routing path (messages 909 2 and 3), installing PATH state on all the routers towards the new 910 base station. When this PATH message reaches the mobile host, a QoS 911 agent on the host generates an RSVP RESV message upstream that 912 follows the reverse forwarding path (messages 5, 6, and 7). Router 0 913 stops forwarding the RESV messages upstream since there is no change 914 in the reservation state to be forwarded. Thus, reservations are 915 restored locally in a timely manner. The case when the mobile host 916 is a sender is fairly simple. A RSVP PATH message is sent by the 917 mobile host after handoff as soon as the HAWAII path setup is 918 complete, resulting in reservations along the new path. 920 Note that the straightforward integration of RSVP and HAWAII is due 921 to the fact that RSVP was designed to blindly follow the routing path 922 established and maintained by an independent routing entity. The 923 HAWAII path setup messages for a mobile host handoff are no different 924 from any other routing changes to which RSVP was designed to respond. 925 Thus, intra-domain handoffs in HAWAII are handled efficiently; since 926 they are localized, they result in fast reservation restorations for 927 the mobile user. In the case of inter-domain handoffs, since HAWAII 928 defaults to Mobile-IP for mobility management, reservation 929 restorations would follow along the procedures elaborated by the 930 Mobile-IP working group. 932 4.3 Reliability 934 Failure of Home Agents is a concern for any approach that is based on 935 Mobile-IP. In HAWAII as well as Mobile-IP, this failure could be 936 tackled through the configuration and advertisement of backup home 937 agents. Other approaches that rely on hot backups are also possible. 938 However, recall that in HAWAII, in the common case of a mobile host 939 not leaving its ``home'' domain, there is no HA involved. This 940 greatly reduces HAWAII's vulnerability to HA failure as compared to 941 the Mobile-IP schemes. Furthermore, HAWAII does not have any foreign 942 agents inside the network architecture, eliminating another source of 943 failure. Consequently, approaches in which the FA and the HA lie in 944 the data path between the correspondent host and the mobile host 945 suffer from reliability concerns not present in the HAWAII approach. 947 Link and router failures are handled through the soft-state refresh 948 mechanism in HAWAII. The routing daemon running at each router would 949 detect these failures and update its default route entry. This will 950 trigger an immediate soft-state refresh of all its host entries to a 951 new uplink router (see Figure 7 for details). This will result in 952 further propagation of soft-state refresh messages until a router 953 that has pre-existing entries for the affected mobile hosts is 954 notified (this will be the domain root router in the worst case). 956 Finally, we need to address the issue of failure of HAWAII process 957 itself without an accompanying router failure. To recover, the 958 HAWAII process must simply be restarted as the subsequent soft-state 959 refreshes correct the existing state. This may be addressed by 960 several means. For instance, a process monitor resident in the same 961 router as the HAWAII process could issue a restart upon detecting a 962 non-responsive process. 964 5 Address Assignment 966 So far we have not made specific assumptions about how each mobile 967 host acquires its IP addresses. In particular, we do not assume any 968 correlation between the domain topology hierarchy and the actual 969 address assignments to mobile hosts. Instead, we assume a flat 970 address assignment algorithm in the domain. To put it another way, 971 mobile hosts are assigned the next available address in the domain 972 when they request one. 974 Recall that, in HAWAII, each host potentially needs two IP addresses: 975 one to operate in its home domain, and (possibly) a second when it 976 moves outside its home domain. The first address can be assigned 977 statically by manual configuration, that then leaves open the 978 question of how inter-domain mobility should be handled. 980 Alternately, and this is the approach preferred by HAWAII, we could 981 use DHCP to acquire both the addresses dynamically. We explore each 982 of these options in the following paragraphs. 984 An option is manual configuration of the home address, but this has 985 implications when the host moves outside its home domain. In this 986 situation, when the host moves outside its home domain, it has to 987 either acquire a co-located care-of-address for itself through manual 988 configuration or other means. Alternately, it might use a foreign 989 agent in the new domain, and act as a ``vanilla'' mobile-IP agent; 990 however, it then needs to attach itself to a new foreign agent every 991 time it moves, even within the new domain, mitigating the gains 992 possible in using HAWAII. 994 The other option is to acquire both the home address and the 995 co-located care-of-address through DHCP [1]. The mobile can retain 996 the home address for the duration of its lifetime; we call this the 997 quasi-permanent address of the mobile. This domain also becomes the 998 mobile host's home domain. Because mobile hosts typically act as 999 clients, as they activate applications, their servers will learn 1000 their IP addresses. If the mobile host moves into a different domain 1001 while powered up, it is assigned a second IP address through DHCP in 1002 the new domain. This address becomes the mobile host's co-located 1003 care-of address. The mobile host still retains the quasi permanent 1004 address assigned in its home network, and packets are tunneled 1005 to/from a home agent in its home network to its current location. In 1006 this way, mobility is transparent to the corresponding servers and 1007 applications. When the host is powered down, it gives back all its 1008 assigned addresses (permanent address and care-of address, if any). 1010 This requires modifying the client side of DHCP so that the client 1011 maintains leasing relationships with two different DHCP servers at 1012 the same time. The exact nature of this modification and its 1013 implications to DHCP are outside the scope of this specification. 1015 The use of a quasi permanent address is similar to the ``dialup'' 1016 model of service provided by Internet Service Providers to fixed 1017 hosts. The difference is that the users in HAWAII are mobile and the 1018 home domain is determined by where the host is powered up rather than 1019 which modem access number is dialed. Apart from requiring fewer IP 1020 addresses, this optimization also results in optimal routing as long 1021 as the user does not move out of a domain while powered up. 1023 6 Security 1025 There are two issues in security: user authentication by the DHCP 1026 server during address assignment, that occurs during power up and 1027 inter-domain moves; and security and authentication related to HAWAII 1028 protocol messages. 1030 This document does not specify solutions for addressing the security 1031 issues related to DHCP server authentication of a mobile user. 1032 Mechanisms such as the RADIUS protocol [7] could be used to perform 1033 the authentication. After the IP address assignment phase, a user 1034 specific key would be downloaded into the current base station. 1036 A second issue is to disallow arbitrary users from sending path setup 1037 messages, thereby subverting another host's traffic. The path setup 1038 messages we propose can be made secure because they all require the 1039 old base station to cooperate. The new base station can ensure that 1040 all handoff update path setup messages are destined for some base 1041 station. When the mobile host is handed off to a new base station, 1042 the old base station approves of the path setup message only if the 1043 mobile host is able to authenticate itself in the path setup message. 1044 The user specific key can then be transferred from the user's old 1045 base station to the new base station. An advantage of this approach 1046 is that authentication is performed at the base stations (except 1047 during power up) in a distributed fashion. This approach also 1048 results in a natural protocol for key management where the 1049 user-specific key is handed off with the user from one base station 1050 to another. If the key management cannot be distributed, it is 1051 possible to have a centralized authentication server and have the 1052 base stations authenticate the path setup messages using this server. 1054 Appendix A - Patent Issues 1056 This is to inform you that Lucent Technologies has applied for and/or 1057 has patent(s) that relates to the attached submission. 1059 This submission is being made pursuant to the provisions of IETF IPR 1060 Policy, RFC 2026, Sections 10.3.1 and 10.3.2. 1062 Lucent Technologies Inc. will offer patent licenses for submissions 1063 made by it which are adopted as a standard by your organization as 1064 follows: 1066 If part(s) of a submission by Lucent is included in a standard and 1067 Lucent has patents and/or pending applications that are essential 1068 to implementation of the included part(s) in said standard, Lucent 1069 is prepared to grant - on the basis of reciprocity (grantback) - a 1070 license on such included part(s) on reasonable, non-discriminatory 1071 terms and conditions. 1073 References 1075 [1] R. Droms, `` Dynamic Host Configuration Protocol,'' Request for 1076 Comments 2131, Mar 1997. 1078 [2] D. Johnson and C. Perkins, ``Mobility Support in IPv6,'' Internet 1079 Draft, Work in Progress, Nov 1998. 1081 [3] G. Malkin, ``RIP Version 2 Carrying Additional Information,'' 1082 Request for Comments 1723, Nov 1994. 1084 [4] D. Mills, "Network Time Protocol (Version 3): Specification, 1085 Implementation and Analysis", RFC 1305, Mar 1992. 1087 [5] S. Mohan and R. Jain, ``Two User Location Strategies for Personal 1088 Communications Services,'' IEEE Personal Communications, Vol 1., 1089 No. 1, pp. 42-50. 1091 [6] C.E. Perkins, ``IP Mobility Support,'' Request for Comments 2002, 1092 Oct 1996. 1094 [7] C. Rigney, A. Rubens, W. Simpson, and S. Willens, ``Remote 1095 Authentication Dial in User Service (RADIUS),'' Request for 1096 Comments 2138, Apr 1997. 1098 [8] D. Zappala and J. Kann., "RSRR: A Routing Interface for RSVP", 1100 [9] B. Braden et. al., ``Resource Reservation Protocol (RSVP) - 1101 Version 1 Functional Specification,'' Request for Comments 2205, 1102 Sep 1997. 1104 Authors' Addresses 1106 R. Ramjee, T. La Porta, S. Thuel, and K. Varadhan 1107 Bell Labs, Lucent Technologies, 1108 101 Crawfords Corner Road, 1109 Holmdel, NJ 07733 (USA) 1110 Phone: 732-949-3306 1111 Fax: 732-949-4513 1112 Email: {ramjee,tlp,thuel,kvaradhan}@bell-labs.com