idnits 2.17.1 draft-ietf-mobileip-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 5) being 60 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: ' 8 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 646: '... message size MUST not exceed 4KB....' RFC 2119 keyword, line 711: '... base station it MUST issue a Mobile I...' RFC 2119 keyword, line 721: '... NAI, the mobile MUST register with th...' RFC 2119 keyword, line 723: '... mobile host MUST register with the ...' RFC 2119 keyword, line 724: '...r case, the mobile MUST be prepared to...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 289 has weird spacing: '...located domai...' == Line 931 has weird spacing: '... else if ME...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The format for a refresh message is shown next. The message could contain multiple entries as part of an aggregate refresh when sent by base stations and routers to their upstream router. However, the message size MUST not exceed 4KB. -- 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 (7 Jul 2000) is 8692 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 669 -- Looks like a reference, but probably isn't: 'RFC2002' on line 734 == Missing Reference: '0' is mentioned on line 1000, but not defined -- Looks like a reference, but probably isn't: '2pi' on line 1000 == Unused Reference: '7' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1377, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1723 (ref. '8') (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 1305 (ref. '9') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2002 (ref. '11') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2138 (ref. '15') (Obsoleted by RFC 2865) -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 17 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 S. Thuel / K. Varadhan / L. Salgarelli 3 draft-ietf-mobileip-hawaii-01.txt Lucent Bell Labs 4 7 Jul 2000 5 Expires: 7 Jan 2001 7 IP micro-mobility support using HAWAII 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 In this contribution, we present HAWAII: a domain-based approach for 33 supporting mobility. HAWAII uses specialized path setup schemes 34 which install host-based forwarding entries in specific routers to 35 support intra-domain micro-mobility and defaults to using Mobile-IP 36 for inter-domain macro-mobility. These path setup schemes deliver 37 excellent performance by reducing mobility related disruption to user 38 applications, and by operating locally, reduce the number of mobility 39 related updates. Also, in HAWAII, mobile hosts retain their network 40 address while moving within the domain, simplifying Quality of 41 Service support. Furthermore, reliability is achieved through 42 maintaining soft-state forwarding entries for the mobile hosts and 43 leveraging fault detection mechanisms built in existing intra-domain 44 routing protocols. 46 Contents 48 1 Changes 3 49 1.1 Changes from version 00 . . . . . . . . . . . . . .. . . . . 3 50 1.2 Changes from version ramjee-00 . . . . . . . . . . .. . . . . 3 52 2 Introduction 4 53 2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.4 Design Overview . . . . . . . . . . . . . . . . . . . . . . 6 57 2.4.1 Network Architecture . . . . . . . . . . . . . . . . . 7 58 2.4.2 Path Setup Schemes . . . . . . . . . . . . . . . . . . 8 59 2.4.3 Soft-State . . . . . . . . . . . . . . . . . . . . . . 9 61 3 Path Setup Schemes 9 62 3.1 Forwarding Path Setup Scheme . . . . . . . . . . .. . . . . 11 63 3.2 Non-Forwarding Path Setup Scheme . . . . . . . . . . . . . . 12 65 4 Protocol Processing 13 66 4.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . 13 67 4.2 Mobile Host Processing . . . . . . . . . . . . . . . . . . . 16 68 4.3 Base Station and Router Processing . . . . . . . . . . . . 17 70 5 Design Implications 21 71 5.1 Scalability . . . . . . . . . . . . . . . . . . . . .. . . . 22 72 5.2 Quality of Service Support . . . . . . . . . . . . . . . . . 23 73 5.3 Reliability . . . . . . . . . . . . . . . . . . . . .. . . . 26 75 6 Address Assignment 26 77 7 Interactions between Mobile IP HA and HAWAII 28 79 8 Security 29 80 1 Changes 82 1.1 Changes from version 00 84 o Added discussion on interactions between HAWAII DRR and Mobile IP 85 Home Agent. 87 1.2 Changes from version ramjee-00 89 o HAWAII is now transparent to hosts that are compatible with 90 Mobile-IP with route optimization, challenge/response and NAI 91 extensions. The mobile host simply sends regular Mobile-IP 92 registration messages and HAWAII is triggered transparently 93 inside the domain. One important benefit of this approach is 94 that the Mobile-IP security model is now directly applicable for 95 authenticating all messages from the mobile host. A second 96 benefit is that movement between Mobile-IP networks and HAWAII 97 domains is seamless. 99 o Clarified how HAWAII path setup updates will work in topologies 100 where there are multiple paths between the mobile host and the 101 domain root router. 103 o Clarified that the assumption in the draft that base stations 104 have IP addresses is used only for discussion purposes. 105 Mobile-IP and HAWAII handoff procedures are only activated when 106 the mobile host's next hop IP node is changed during the 107 handoff; this next hop may or may not be a base station. 109 o Clarified the discussion on the reliability mechanisms of 110 HAWAII. The emphasis is on leveraging fault detection mechanisms 111 from existing intra-domain routing protocols for increased 112 reliability rather than defining special purpose recovery 113 mechanisms for mobility agents. 115 o Added a metric field to HAWAII messages in order to distinguish 116 alternate paths in certain non-tree topologies. 118 o Added routing-lifetime field to HAWAII refresh message to 119 accurately synchronize soft-state timers. 121 o Added a constraint on the size of HAWAII aggregate refresh 122 messages to 4KB. 124 o Draft name changed from 125 draft-ramjee-micro-mobility-hawaii-00.txt to 126 draft-ietf-mobileip-hawaii-00.txt 128 2 Introduction 130 Mobile-IP is the current standard for supporting macro-mobility in IP 131 networks [11]. Mobile-IP defines two entities to provide mobility 132 support: a home agent (HA) and a foreign agent (FA). The HA is 133 statically assigned to a mobile host based on the permanent home IP 134 address of the mobile host. The FA is assigned to the mobile host 135 based on its current location. The FA has associated with it an IP 136 address called the care-of address. Packets sent to the mobile host 137 are intercepted by the HA and tunneled to the FA at the care-of 138 address. The FA then decapsulates the packets and forwards them 139 directly to the mobile host. Thus, Mobile-IP provides a good 140 framework for allowing users to roam outside their home networks. 142 When Mobile-IP is used for micro-mobility support, it results in high 143 control overhead due to frequent notifications to the HA and high 144 latency and disruption during handoff. Also, in the case of a 145 Quality of Service (QoS) enabled mobile host, acquiring a new care-of 146 address on every handoff would trigger the establishment of new QoS 147 reservations from the HA to the FA even though most of the path 148 remains unchanged. Thus, while Mobile-IP should be the basis for 149 mobility management in wide-area wireless data networks, it has 150 several limitations when applied to wide-area wireless networks with 151 high mobility users that may require QoS. Our aim is to extend Mobile 152 IP to address these limitations using Handoff-Aware Wireless Access 153 Internet Infrastructure (HAWAII). 155 HAWAII operates entirely within the administrative domain of the 156 wireless access network. In order to keep HAWAII transparent to 157 mobile hosts, the mobile host runs the standard Mobile-IP protocol 158 with NAI, route optimization and challenge/response extensions. To 159 reduce the frequency of updates to the HA and avoid high latency and 160 disruption during handoff, in HAWAII, we split the processing and 161 generation of Mobile-IP registration messages into two parts: 162 between the mobile host and the base station and between the base 163 station and the HA. Note that this separation is needed for any 164 approach that desires to reduce updates to the HA. For example, 165 similar separation at the foreign agent is proposed in the Mobile IP 166 Regionalized Tunnel Management approach as well [4]. 168 Another issue concerning the integration of HAWAII and Mobile-IP 169 protocols is the choice of a co-located care-of address (CCOA) option 170 in HAWAII. As we shall see later, the use of a CCOA option has 171 several advantages in terms of QoS support. On the other hand, in 172 basic Mobile-IP, hosts that use CCOA are expected to always contact 173 the HA directly. Again, this is in conflict with reducing the 174 frequency of updates to the HA. We advocate that the mobile hosts be 175 able to register with a base station even while using the CCOA 176 option. The base station helps reduce the frequency of updates to 177 the HA by processing the registrations locally and also ensures 178 smooth handoff by forwarding packets if necessary. This approach 179 also allows networks to enforce security and authentication measures 180 in their domain. Thus, in our approach, data packets are sent 181 directly from the HA to the mobile host while registrations are 182 processed in two stages at the base station and the HA. 184 2.1 Goals 186 We have three design goals in HAWAII: 188 o Achieve good performance by reducing update traffic to home 189 agent and corresponding hosts, avoiding triangular routing where 190 possible, and limiting disruption to user traffic. 192 o Provide intrinsic support for QoS in the mobility management 193 solution, including allowing per flow QoS and limiting the 194 number of reservations that must be re-established when hosts 195 move. 197 o Enhance reliability. We require HAWAII to be no less fault 198 tolerant than existing Mobile-IP proposals, and we explore 199 additional mechanisms to improve the robustness of mobility 200 support. 202 2.2 Assumptions 204 Our proposal for supporting mobility hinges on the assumption that 205 most user mobility is local to a domain, in particular, an 206 administrative domain of the network. Since an administrative domain 207 is under the control of a single authority, it is possible to relax 208 the assumption that there is no special support for mobility 209 available in the domain infrastructure. Therefore, we consider 210 optimizations in routing and forwarding in the domain routers for 211 more efficient support of intra-domain mobility. 213 2.3 Terminology 215 Domain 217 A division of the wireless access network. It consists of one or 218 more routers and multiple base stations. It will appear as a 219 subnet to routers external to the domain. 221 Domain Root Router 222 The gateway router into a domain is called the domain root router. 224 Home Domain 226 Each mobile user is assigned a home domain based on its Network 227 Access identifier(NAI). The NAI [5] field in the registration 228 message will help identify the mobile host's domain. 230 Foreign Domain 232 Any domain that is not the mobile host's home domain is referred 233 to as its foreign domain. 235 Path Setup Scheme 237 A particular method of updating the routers in a domain so that 238 connectivity to the mobile host is maintained across handoffs. 240 2.4 Design Overview 242 In this section, we present the architecture of HAWAII. There are 243 three separate components to HAWAII: 1) To achieve maximum 244 transparency in mobility, we consider a two-level hierarchy along 245 domain boundaries, and define separate mechanisms for intra-domain 246 mobility and inter-domain mobility. We conjecture that mobility 247 across domains is likely to be a rare occurrence and default to using 248 Mobile-IP for inter-domain mobility. To provide straight-forward QoS 249 support, we assign a unique, co-located care-of address to the mobile 250 host; 2) To maintain end-to-end connectivity with little disruption 251 as the mobile host moves, we establish special paths to the mobile 252 host; and finally, 3) To provide a degree of tolerance to router or 253 link failures within the network, we use soft-state mechanisms for 254 maintaining forwarding state. We discuss each of these issues 255 separately in the following sections. 257 2.4.1 Network Architecture 259 ___ ___ 260 | | Internet | | 261 | | Core | | 262 |___| |___| 263 x\ / 264 x\ / 265 x\ ____/ 266 x| | Regular IP Packets xxxxx 267 x | Encapsulated IP Packets @@@@@ 268 |x___| Domain Boundaries ***** 269 x /\ 270 ********************x / \************************* 271 * x /* *\ * 272 * Home x / ** \ Foreign * 273 * Domain _x_/ * \ ___ Domain * 274 * Root --->|x@@@@@@@@@@@@@@@ |<--Root * 275 * Router |x | * | @ | Router * 276 * |x__| * |_@_| * 277 * Home Domain x * @ Foreign Domain * 278 * x x x * @@@ * 279 * x x x * @ @ @ * 280 * x x x * @ @ @ * 281 * x x x * @ @ @ * 282 * x x x * @ @ @ * 283 * ___ x * ___ * 284 * | | * | | Mobile * 285 * | | * | | Host * 286 * |___|----->------->--*--->----->--->|___| * 287 * * * 288 * Movement Movement across domains Movement within * 289 * within domain (HA notified of co-located domain (no HA * 290 * (no HA involved) care-of address) notification) * 292 Figure 1: Hierarchy 294 A common approach for providing transparent mobility to correspondent 295 hosts is to divide the network into hierarchies. In HAWAII we define 296 a hierarchy based on domains. The network architecture is 297 illustrated in Figure 1. The gateway into each domain is called the 298 domain root router. Each host has an IP address and a home domain. 299 For the moment, we defer the discussion of how this address could be 300 assigned to Section 6. When moving in its home domain, the mobile 301 host retains its IP address. Packets destined to the mobile host 302 reach the domain root router based on the subnet address of the 303 domain and are then forwarded over special dynamically established 304 paths to the mobile host. This allows the home domain to cover a 305 large area made up of hundreds of base stations, thereby increasing 306 the probability that a mobile host is in its home domain. For these 307 mobile hosts, a home agent is not involved in the data path, 308 resulting in enhanced reliability and efficient routing. 310 When the mobile host moves into a foreign domain, we revert to 311 traditional Mobile-IP mechanisms. If the foreign domain is also 312 based on HAWAII, then the mobile host is assigned a co-located 313 care-of address from its foreign domain. Packets are tunneled to the 314 care-of address by a home agent in its home domain. When moving 315 within the foreign domain, the mobile host retains its care-of 316 address unchanged (thus, the HA is not notified of these movements); 317 connectivity is maintained using dynamically established paths in the 318 foreign domain. 320 The design choices of using co-located care-of addresses and 321 maintaining the mobile host address unchanged within a domain 322 simplifies per flow QoS support as discussed in Section 5.2. One 323 drawback of using the co-located care-of address option is the need 324 for two IP addresses for each mobile host that is away from its home 325 domain. This exacerbates the limited IP address availability 326 problem. One possible optimization is to adapt the ``dialup'' model 327 used by ISPs to wireless networks. This is discussed in Section 6. 329 2.4.2 Path Setup Schemes 331 As described above, HAWAII assigns a unique address for each mobile 332 host that is retained as long as the mobile host remains within its 333 current domain. In this context, maintaining end-to-end connectivity 334 to the mobile host requires special techniques for managing user 335 mobility. HAWAII uses path setup messages to establish and update 336 host-based routing entries for the mobile hosts in selective routers 337 in the domain so that packets arriving at the domain root router can 338 reach the mobile host. The choice of when, how, and which routers 339 are updated constitutes a particular path setup scheme. In 340 Section 3, we describe two such path setup schemes. 342 One important question in using host-based forwarding in the domain 343 routers is scalability. It is because of scalability considerations 344 that we use Mobile-IP mechanisms for inter-domain mobility. In 345 Section 5.1, we present a numerical example showing how a single 346 domain in HAWAII can cover an area of approximately 1000Km2 for 347 typical network configuration values, without any difficulty in 348 processing mobility related updates. 350 2.4.3 Soft-State 352 The notion of ``soft-state'' refers to state established within 353 routers that needs to be periodically refreshed; otherwise, it is 354 removed automatically when a preset timer associated with that state 355 expires. The HAWAII path state within the routers is soft-state. 356 This increases the robustness of the protocol to router and link 357 failures. 359 Our protocol uses two types of control messages, updates and 360 refreshes, to establish and maintain the soft-state respectively. 361 Path setup updates are triggered at the base station following 362 Mobile-IP registrations sent by the mobile host during power up and 363 following handoffs. These messages are explicitly acknowledged by 364 the recipient. Note that the HAWAII handoff procedures are only 365 activated when the mobile host's next hop IP node is changed during 366 the handoff. Thus, for discussion, we assume base stations have IP 367 routing functionality in this draft. In actual deployed networks, 368 the mobile host's next hop IP node may or may not be a base station. 370 The mobile host also sends periodic Mobile-IP renewal registrations 371 to the base station. The base stations and routers, in turn, send 372 HAWAII aggregate refresh messages periodically in a hop-by-hop manner 373 to the routers upstream of the mobile hosts. As we shall see in the 374 following sections, HAWAII messages are sent to only selected routers 375 in the domain, resulting in very little overhead associated with 376 maintaining soft-state. 378 3 Path Setup Schemes 380 Path setup update messages are sent by the mobile host during power 381 up and following a handoff. We first discuss the update procedure 382 for power up. We then describe two algorithms by which update 383 messages in HAWAII are used to re-establish path state after 384 handoffs. 386 When the mobile host powers up, it sends a Mobile-IP registration 387 message to its nearest base station. The base station then 388 propagates a HAWAII path setup update message to the domain root 389 router using a configured default route. Each router in the path 390 between the mobile host and the domain root router adds a forwarding 391 entry for the mobile host. Finally, the domain root router sends 392 back an acknowledgement to the base station which then sends a 393 Mobile-IP registration reply to the mobile host. At this time, when 394 packets destined for the mobile host arrive at the domain root router 395 based on the subnet portion of the mobile host's IP address, the 396 packets are routed within the domain to the mobile host using the 397 host-based forwarding entries just established. These host-based 398 forwarding entries are soft-state entries that are kept alive by 399 periodic hop-by-hop refresh messages. 401 Note that other routers in the domain have no specific knowledge of 402 this mobile host's IP address. In the case of mobile to mobile 403 communication, packets arriving at a router that has no specific 404 host-based entry are routed using a default route. The packets 405 eventually reach an upstream router (in the worst case, the domain 406 root router) which has a forwarding entry for the mobile host. 408 When the topology has multiple paths between the base station and the 409 domain root router, the base station and routers will have multiple 410 routes for the domain root router (or multiple default routes). Each 411 base station and router can choose any of these routes to forward the 412 path setup message for a particular mobile host that has powered up. 413 In this case, the base station or router must ensure that subsequent 414 refreshes for a given mobile host always goes through the same route. 415 Thus, all the packets for a particular mobile host will arrive on the 416 same path from the domain root router resulting in no re-ordering. 417 At the same time, multiple paths between the domain root router and 418 the base station are utilized for the different users attached to a 419 base station. 421 We now describe the operations of two path setup schemes used to 422 re-establish path state when the mobile host moves from one base 423 station to another within the same domain. We assume a tree-based 424 topology for the discussion although the path setup schemes work with 425 any arbitrary topology. For the remaining subsections, let us define 426 the cross-over router as the router closest to the mobile host that 427 is at the intersection of two paths, one between the domain root 428 router and the old base station, and the second between the old base 429 station and the new base station. In both path setup schemes, 430 forwarding entries during handoff are added so that packets are 431 either forwarded from the old base station or diverted from the 432 cross-over router to the new base station. This property ensures us 433 against the possibility of persistent loops after the handoff update. 435 There are two variants of the path setup schemes, motivated by two 436 types of wireless networks. The Forwarding scheme is optimized for 437 networks where the mobile host is able to listen/transmit to only one 438 base station as in the case of a Time Division Multiple Access (TDMA) 439 network. The Non-Forwarding scheme is optimized for networks where 440 the mobile host is able to listen/transmit to two or more base 441 stations simultaneously for a short duration, as in the case of a 442 WaveLAN or Code Division Multiple Access (CDMA) network. These are 443 described below. 445 3.1 Forwarding Path Setup Scheme 447 In this path setup scheme, packets are first forwarded from the old 448 base station to the new base station before they are diverted at the 449 cross-over router. 451 | (0):1.1.1.1->B 452 --------- (4):1.1.1.1->C 453 | A | 454 ROUTER 0 | | 455 | B C | 456 @@@@@>--------- @@@@@ 457 @ / @@@@ \ @ 458 4 @ / @ @ \ @ 5 459 @ / @ @ \ v 460 ROUTER 1---------@ @--------- ROUTER 2 461 | A |@ @| A | 462 (0):1.1.1.1->B | |@ @| | (0):Default->A 463 (3):1.1.1.1->A | B |@ @| B | (5):1.1.1.1->B 464 ---------@ @--------- 465 ^ | @ @ | @ 466 3 @ | @ @ | @ 6 467 @ | @ 2 @ | v 468 OLD BS -----<@ @ ----- NEW BS 469 / A \ @/ A \ 470 (0):1.1.1.1->B | | | | (0):Default->A 471 (2):1.1.1.1->A \ B / \ B / (6):1.1.1.1->B 472 ----- 1 $$>----- 473 $ $ 7 474 $ $ 475 ---- <$$$$$ 476 MOBILE / \ 477 USER \ / $: Mobile-IP messages 478 ---- @: HAWAII messages 479 IP:1.1.1.1 481 Figure 2: Forwarding path setup scheme 483 The Forwarding scheme is illustrated in Figure 2. The forwarding 484 table entries are shown adjacent to the routers. These entries are 485 prepended with a message number indicating which message was 486 responsible for establishing the entry (a message number of zero 487 indicates a pre-existing entry). The letters denote the different 488 interfaces. A Mobile-IP registration is first sent by the mobile 489 host to the new base station. The message contains the old base 490 station's address as part of the Previous Foreign Agent Notification 491 Extension (PFANE) [12]. The new base station then sends a path setup 492 update to the old base station. The old base station performs a 493 routing table lookup for the new base station and determines the 494 interface, interface A, and next hop router, Router 1. The base 495 station then adds a forwarding entry for the mobile host's IP address 496 with the outgoing interface set to interface A. It then forwards the 497 message to Router 1 (message 3). Router 1 performs similar actions 498 and forwards the message to Router 0. Router 0, the cross-over 499 router in this case, adds forwarding entries that result in new 500 packets being diverted to the mobile host at the new base station. 501 It then forwards the message towards the new base station. 502 Eventually the message reaches the new base station (message 6). The 503 new base station changes its forwarding entry and sends a Mobile-IP 504 registration reply to the mobile host (message 7). 506 Note that only the new and old base stations, and the routers 507 connecting them, are involved in processing the path setup message. 508 Also, only routers on the path between the new base station and the 509 domain root router will receive the periodic refresh messages. 510 Therefore, the entries in Router 1 and the old base station, which 511 are no longer on this path, will time-out, while the entries in 512 Routers 0 and 2, and the new base station will get refreshed. 514 3.2 Non-Forwarding Path Setup Scheme 516 In this path setup scheme, as the path setup message travels from the 517 new base station to the old base station, data packets are diverted 518 at the cross-over router to the new base station, resulting in no 519 forwarding of packets from the old base station. 521 The Non-Forwarding scheme is illustrated in Figure 3. In this case, 522 when the new base station receives a Mobile-IP registration with the 523 PFANE field, it adds a forwarding entry for the mobile host's IP 524 address with the outgoing interface set to the interface on which it 525 received this message. It then performs a routing table lookup for 526 the old base station (identified using the PFANE field in the 527 registration message) and determines the next hop router, Router 2. 528 The new base station then forwards the path setup message to Router 2 529 (message 2). This router performs similar actions and forwards the 530 message to Router 0. At Router 0, the cross-over router in this 531 case, forwarding entries are added such that new packets are diverted 532 directly to the mobile host at the new base station. Eventually the 533 message reaches the old base station (message 5). The old base 534 station changes its forwarding entry and sends an acknowledgement of 535 the path setup message back to the new base station which then sends 536 a Mobile-IP registration reply to the mobile host (message 7). 538 | (0):1.1.1.1->B 539 --------- (3):1.1.1.1->C 540 | A | 541 ROUTER 0 | | 542 | B C | 543 @@@@@@---------<@@@@@ 544 @ / @@@@ \ @ 545 4 @ / @ @ \ @ 3 546 v / @ @ \ @ 547 ROUTER 1---------@ @--------- ROUTER 2 548 | A |@ @| A | 549 (0):1.1.1.1->B | |@ @| | (0):Default->A 550 (4):1.1.1.1->A | B |@ @| B | (2):1.1.1.1->B 551 ---------@ @--------- 552 @ | @ @ | ^ 553 5 @ | @ 6 @ | @ 2 554 v | @ @ | @ 555 OLD BS ----- @ v---- NEW BS 556 / A \ / A \ 557 (0):1.1.1.1->B | | | | (0):Default->A 558 (5):1.1.1.1->A \ B / 7 \ B / (1):1.1.1.1->B 559 ----- $$$--^-- 560 $ $ 561 $ $ 1 562 --v- $$$$$$ 563 MOBILE / \ 564 USER \ / $: Mobile-IP messages 565 ---- @: HAWAII messages 566 IP:1.1.1.1 568 Figure 3: Non-Forwarding path setup scheme 570 4 Protocol Processing 572 In this section, we describe the protocol processing details of 573 HAWAII path setup schemes. We first describe the format for the path 574 setup update and refresh messages. We then present the processing at 575 the mobile host and finally, the protocol processing at the base 576 stations/routers. 578 4.1 Message Formats 580 In this section, we discuss the message formats for the HAWAII 581 messages sent between base stations and routers within a domain. The 582 format for messages sent between the mobile hosts and base stations 583 follow the Mobile IP standard with the extensions described later. 585 The format of a HAWAII update path setup message sent by base 586 stations and routers is shown below. The message is sent using the 587 UDP protocol to a reserved port. Power up updates (type 1) are sent 588 from the current base station towards the domain root router. 589 Handoff updates (type 2) are sent from the old base station in the 590 case of the Forwarding scheme, and from the new base station in the 591 case of the Non-Forwarding scheme. At present, we do not have a 592 power down update as we rely on the time out of the soft state 593 forwarding entries. It is conceivable to define an explicit tear 594 down message to handle this case. 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |Version| Type | Reason | Scheme + 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Mobile Host Address | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | rsv |S|B|D|M|G|V|rsv| Mobile IP Lifetime | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Metric | Routing Lifetime | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Old Base Station | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | New Base Station | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 + Timestamp + 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Extensions ... 615 +-+-+-+-+-+-+-+- 617 Version 1 618 Type 1 (Power up update), 2 (handoff update), 619 3 (acknowledgement) 620 Reason Used only for Type 3 messages 621 0 accepted 622 1 poorly formatted message 623 2 authentication failed 624 3 Scheme not supported 625 4 Resource not available 626 Scheme 1 (Forwarding), 2 (Non-Forwarding) 627 Mobile host Address Home address in Home domain, 628 Care-of address in Foreign domain 629 rsv Reserved, sent as 0 630 S,B,D,M,G,V Flags from Mobile IP registration 631 Mobile IP lifetime Lifetime field in Mobile IP registration 632 Metric Distance to the mobile host in hops 633 Routing Lifetime Soft state timer value 634 Old Base Station Old Base Station IP address for Type 2 635 0.0.0.0 for Type 1 636 New Base Station New Base Station IP address for Type 2 637 Current Base Station for Type 1 638 Timestamp Timestamp formatted as in 639 Network Time Protocol [9]. 640 Extensions Authentication field 641 Wireless link specific fields, for study 643 The format for a refresh message is shown next. The message could 644 contain multiple entries as part of an aggregate refresh when sent by 645 base stations and routers to their upstream router. However, the 646 message size MUST not exceed 4KB. 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |Version| Type | Reason | Size + 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Mobile Host Address[1] | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Metric[1] | Routing Lifetime[1] | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | | 657 + Timestamp[1] + 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 ... 661 ... 662 ... 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Mobile Host Address[N] | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Metric[N] | Routing Lifetime[N] | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 + Timestamp[N] + 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Extensions ... 673 +-+-+-+-+-+-+-+- 675 Version 1 676 Type 4 (refresh) 677 Reason 0 (normal) 678 1 (triggered due to link/host failure) 679 Size Number of mobile host entries 680 Mobile host Address Host-entry address 681 Metric Distance to the mobile host in hops 682 Routing Lifetime Soft state timer value (remaining) 683 Timestamp Host-entry timestamp 684 Extensions Authentication field 686 4.2 Mobile Host Processing 688 Since the mobile host is only aware of Mobile-IP and not HAWAII, it 689 executes a regular Mobile-IP client state machine and issues 690 Mobile-IP registration messages with the various extensions discussed 691 below. Our goal is to ensure that there is sufficient information at 692 the mobile host and the base station so that seamless mobility 693 between HAWAII and Mobile-IP domains is possible. 695 Recall that HAWAII divides the access network into domains. We 696 propose to use Network Access Identifiers (NAI's) [1] to identify the 697 different HAWAII domains. Also, each mobile host in HAWAII is 698 associated with a home domain and the Mobile-IP Home Agent is 699 involved only when the mobile host is visiting a foreign domain. 700 However, even while the mobile host is moving in the HAWAII home 701 domain, we require that the host send registrations to the base 702 station on every handoff so that the HAWAII host-based entries are 703 re-established locally. This is accomplished as follows. 705 Let us assume that each mobile host (user) is configured (either 706 statically or dynamically) with a NAI, home address, netmask, and a 707 home domain. The netmask at the mobile host is setup (for example, a 708 netmask of all 1's) so that every base station advertisement appears 709 to the mobile host as though it is served by a foreign network as far 710 as the Mobile-IP client is concerned. In this scenario, whenever the 711 host detects a change of base station it MUST issue a Mobile IP 712 registration request to the new base station. We use these 713 registrations to trigger HAWAII path setup schemes inside the domain. 715 Another issue is the need for a mobile host to acquire a co-located 716 care-of address when the host is in a HAWAII foreign domain and use 717 its home address in the HAWAII home domain. We compare the NAI 718 advertised by the base station with the mobile host's NAI to 719 distinguish whether a mobile host is in its HAWAII home domain or a 720 HAWAII foreign domain. If the NAI advertised by the base station 721 matches the mobile host's NAI, the mobile MUST register with the base 722 station using the advertised (non co-located) COA; otherwise, the 723 mobile host MUST register with the base station using a co-located 724 COA (CCOA). In the latter case, the mobile MUST be prepared to 725 decapsulate packets arriving at its interface. Note that, in either 726 case, this registration is used for establishing host-based entries 727 in the domain and updating the home agent on inter-domain handoffs; 728 the base station in HAWAII does not perform any decapsulation. 730 Whether the mobile host is using a co-located COA or not, the request 731 MUST include a Previous-Foreign Agent Notification extension [12] 732 (PFANE) unless this is the first registration after being powered up. 733 The registration MUST also include all the mandatory extensions 734 defined in [RFC2002], the mobile-foreign authentication extension, 735 the mobile-challenge-response extension [14] and the NAI 736 extension [5]. 738 Furthermore, the mobile host MUST be prepared to receive registration 739 replies generated by the base station without the involvement of the 740 HA, thus not including the mobile-home authentication extension. 741 Nevertheless, such registration replies MUST include a valid 742 mobile-foreign authentication extension. 744 The details of processing at the mobile host are shown in Figure 4. 746 -------------------------------------------------------------------- 747 Figure 4: Mobile host processing 748 -------------------------------------------------------------------- 749 1. If the OLD BS and NEW BS' NAI match /* intra-domain move */ 750 If the mobile host's NAI matches the NEW BS advertised NAI 751 /* HAWAII home domain */ 752 1.1 send Mobile-IP registration to NEW BS using advertised COA. 753 else /* HAWAII foreign domain */ 754 1.2 send Mobile-IP registration to NEW BS using previous CCOA. 755 endif 756 else /* inter-domain move */ 757 1.3 acquire CCOA through DHCP 758 1.4 send Mobile-IP registration to NEW BS using new CCOA. 759 endif 760 -------------------------------------------------------------------- 762 4.3 Base Station and Router Processing 764 We now describe base station and router processing of HAWAII 765 messages. While routers process only HAWAII messages, base stations 766 have the additional responsibility of implementing the Mobile-IP 767 foreign agent functionality (without the decapsulation function) and 768 originating HAWAII messages for processing within the domain. 770 The base stations periodically issue agent advertisement messages, 771 and reply to agent-solicitation messages. Agent advertisement 772 messages MUST include the foreign-agent-challenge extension [14] and 773 the NAI of the administrative domain to which the base station 774 belongs. The base station authenticates the mobile host's request 775 using the challenge mechanisms defined in [14] in addition to the 776 authentication mechanisms defined in basic Mobile IP. 778 On receipt of a registration request with a valid mobile-foreign 779 authentication and a valid challenge-response, the base station MUST 780 check whether the mobile host's NAI present in the request matches 781 the NAI of the domain to which it belongs. If the two match, the 782 base station SHOULD reject any request that is registering the mobile 783 with a co-located COA. If the registration is valid, the base station 784 generates HAWAII power-up or handoff update messages based on whether 785 the PFANE field is present or not. When necessary, the base station 786 is also responsible for registering with the home agent (see Figures 787 5 and 7 for the details). 789 The pseudo-code for processing power up update messages is shown in 790 Figures 5 and 6. Each node adds an entry for the mobile host and 791 forwards the message to next hop router along its ``default'' route. 792 Note that we assume that the default route is the same as the route 793 to a domain root router (gateway). When the message reaches a domain 794 root router, an acknowledgement is sent to the base station which 795 generates a registration replay to the mobile host. 797 -------------------------------------------------------------------- 798 Figure 5: Power up processing at base station 799 -------------------------------------------------------------------- 800 1. Receive registration message from a new mobile host on Interface A 801 (The PFANE is not present since this is the first registration) 802 2. If mobile host's NAI matches domain's NAI 803 /* This domain is the host's home domain */ 804 2.1 Authenticate message: if failure, abort with a negative reply 805 2.2 Add/Update entry {MH IP ADDRESS -> Interface A}, set timer 806 2.3 Send HAWAII Power up update message to upstream neighbor 807 along one of the default routes 808 else /* This domain is the host's foreign domain */ 809 2.4 Send message to the mobile host's home agent 810 2.5 If registration is accepted by home agent, execute 2.2 811 endif 812 3. If HAWAII ack is received, send registration accept reply with 813 mobile-foreign authentication extension 814 -------------------------------------------------------------------- 815 Figure 6: HAWAII power up update processing at router 816 -------------------------------------------------------------------- 817 1. Receive Power Up Update message from mobile host on Interface A 818 Message contains MH IP ADDRESS, METRIC, TIMESTAMP 819 2. Add/Update entry {MH IP ADDRESS -> Interface A}, set timer 820 3. If I am the Domain Root Router 821 3.1 Generate an acknowledgement back to the base station 822 else 823 3.2 Update METRIC and forward update to upstream neighbor 824 along one of the default routes 825 endif 826 -------------------------------------------------------------------- 828 The pseudo-code for processing a update message during handoff in the 829 Forwarding and Non-Forwarding schemes is shown in Figure 7(a) and 830 Figure 7(b) respectively. The basic processing of an update message 831 at a router is fairly simple: on receiving the message, modify the 832 forwarding entry for the mobile host in the kernel and forward the 833 update message towards the new or the old base station depending on 834 whether the Forwarding or Non-Forwarding schemes are used. 836 -------------------------------------------------------------------- 837 Figure 7(a): HAWAII handoff processing for the Forwarding scheme 838 -------------------------------------------------------------------- 839 1. If Registration message with PFANE extension is received, 840 If mobile host's NAI matches domain's NAI /* intra-domain */ 841 1.1 send an Update message to Old base station. 842 else /* inter-domain */ 843 1.2 send registration to home agent 844 1.3 If registration is accepted by home agent, execute 1.1 845 endif 846 endif 847 2. Receive Update message on Interface A 848 Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP 849 3. If NEW BS ADDRESS matches one of local interface addresses then 850 3.1 Let Interface B be the local interface 851 else 852 3.2 Look up routing table for NEW BS ADDRESS and determine 853 next hop router and outgoing interface Interface B 854 endif 855 4. If TIMESTAMP is newer or METRIC is smaller for same TIMESTAMP then 856 Add/Update entry {MH IP ADDRESS -> Interface B}, set timer 857 endif 858 5. If NEW BS ADDRESS matches one of local interface addresses then 859 5.1 Update Mobile-IP lifetime and generate registration reply to MH 860 else 862 5.2 Update METRIC and forward message to next hop router in step 3.2 863 endif 864 -------------------------------------------------------------------- 865 Figure 7(b): HAWAII handoff processing for the Non-forwarding scheme 866 -------------------------------------------------------------------- 867 1. If Registration message with PFANE extension is received, 868 If mobile host's NAI matches domain's NAI /* intra-domain */ 869 1.1 obtain MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP 870 else /* inter-domain */ 871 1.2 send registration to home agent 872 1.3 If registration is accepted by home agent, execute 1.1 873 endif 874 go to step 3. 875 endif 876 2. Receive Update message from neighbor on Interface A 877 Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP 878 3. If TIMESTAMP is newer or METRIC is smaller for same TIMESTAMP then 879 Add/Update entry {MH IP ADDRESS -> Interface A}, set timer 880 endif 881 4. If OLD BS ADDRESS matches one of local interface addresses then 882 4.1 Generate an acknowledgement back to the NEW BS 883 else 884 4.2 Look up routing table to find next hop router for OLD BS ADDRESS 885 Update METRIC and forward/generate message to next hop router 886 endif 887 5. If HAWAII ack is received 888 Update Mobile-IP lifetime and generate registration reply to MH 889 -------------------------------------------------------------------- 891 The soft-state refresh messages are sent independently by each of the 892 nodes on a hop-by-hop basis. The mobile host sends Mobile-IP 893 registration renewals to the base station every TH seconds. The base 894 station is responsible for keeping alive the mobile's registration 895 with its home-agent, generating registration requests on behalf of 896 the mobile. Such surrogate requests [4] do not contain a valid 897 mobile-home authentication extension, but MUST contain a valid 898 foreign-home authentication extension. Such registrations are 899 generated by the base station when the lifetime of the mobile host's 900 registration with its HA is due to expire. 902 The base stations and routers also send HAWAII refreshes to their 903 upstream routers (determined based on their default route to the 904 domain root router) every TR seconds. Typically TH would be much 905 larger than TR in order to conserve the limited wireless bandwidth. 906 When the refresh message is received, the expiry timer corresponding 907 to the refresh entry is updated. This involves no update to the 908 kernel routing table and can be done very efficiently. Furthermore, 909 a single refresh message can refresh several mobile hosts, thus 910 amortizing on the cost of sending/receiving the message. The 911 pseudo-code for processing a refresh message is shown in Figure 8. 912 One important point to note is the need for a user-specific timestamp 913 and metric in the path setup messages. The timestamp guards against 914 a potential race-condition involving a soft-state refresh from an old 915 base station competing with a recent update message from a new base 916 station. The metric resolves cases in non-tree topologies where race 917 conditions between two independent refreshes with the same timestamp 918 can be resolved. 920 -------------------------------------------------------------------- 921 Figure 8: HAWAII refresh processing for both schemes 922 -------------------------------------------------------------------- 923 1. Receive Refresh message from authenticated neighbor on Interface A 924 Message contains multiple tuples of {MH IP ADDRESS, TIMESTAMP} 925 2. For each tuple do 926 If entry exists for MH IP ADDRESS 927 If TIMESTAMP is greater than or equal to timestamp in entry 928 If entry already has interface as Interface A 929 /* Most common case - no failure */ 930 2.1 reset timer on forwarding entry 931 else if METRIC is not greater 932 /* interface change failure, don't propagate up */ 933 2.2 update entry {MH IP ADDRESS -> Interface A}, set timer 934 endif 935 endif 936 else 937 /* Non-existent MH entry failure, propagate up */ 938 2.3 Add entry {MH IP ADDRESS -> Interface A}, set timer 939 2.4 Send immediate update (batched) using the default route 940 endif 941 3. Periodically send batch refresh upstream for all entries 942 4. When the default route changes 943 send batch refresh upstream for all entries 944 ------------------------------------------------------------------- 946 5 Design Implications 948 In this section, we illustrate the advantages of the HAWAII approach 949 by studying the implications on scalability, QoS support, and 950 reliability. 952 5.1 Scalability 954 In this section, we illustrate the advantages of HAWAII's local 955 mobility through a numerical example. Consider a domain with 956 configuration parameters as shown in Table 1. The domain is in the 957 form of a tree with three levels: at the highest level there is a 958 single domain router; at the second level there are seven 959 intermediate routers; at the third and lowest level, there are 140 960 base stations (twenty per router). We also assume that the coverage 961 area of a base station is a square with a given perimeter. For this 962 configuration, we compute the rate of mobility related messages for 963 two different approaches: 1) Mobile-IP approach where FAs are 964 present at each base station and are served by a HA and 2) the HAWAII 965 approach where the HA is at the domain root router. 967 Table 1: Domain Configuration values 968 -------------------------------------------------------------------- 969 Item Type Value 970 -------------------------------------------------------------------- 971 B Base stations per domain root router 140 972 R Second level router per domain root router=(B/S) 7 973 D User density (active users) 39 per sq km 974 V User speed 112 km/hr 975 TR Router refresh timer for HAWAII 30 seconds 976 Y No. of mobile host entries in refresh in HAWAII 25 977 TM Mobile-IP binding lifetime 300 seconds 978 Z Fraction of users in foreign domain in HAWAII 0.1 979 LB Perimeter of base station 10.6 km 980 A Coverage area of domain = B*LB*LB/16 = 980 sq km 981 LD Perimeter of domain = SquareRoot(A)*4 = 125.2 km 982 LR Perimeter of 2nd level router=SquareRoot(A/R)*4 47.3 km 983 N Number of users in domain = A*D = 38,720 984 -------------------------------------------------------------------- 986 First note that the coverage area of this domain is quite large: 987 A = 980km2. If we need to scale to larger areas, we would use 988 Mobile-IP to handoff between these domains. The number of forwarding 989 entries at the domain root router in the case of the HAWAII approach 990 is the same as the total number of active users in the domain, and is 991 N = 38, 220. This is well within the capability of a modern router. 992 Furthermore, a majority of these entries are completely specified 993 entries of hosts from a particular domain/subnet. In this case, 994 perfect hashing is possible resulting in O(1) memory access for IP 995 route lookup. Thus, route lookup for data forwarding can be done 996 efficiently at the domain routers. 998 We now compute the impact of mobility-related messages for the two 999 approaches. First consider a system based on Mobile-IP. Assuming the 1000 direction of user movement is uniformly distributed over [0,2pi] and 1001 using a fluid flow mobility model [10], the rate of mobile hosts 1002 crossing a boundary of perimeter l at a speed V is given by 1003 f(l)=(D*V*l)/(3600*pi). Since user handoffs between any two base 1004 stations in the domain generates an update registration at the HA, 1005 the number of mobility related updates at the HA from B base stations 1006 is f(LB)*B. The rate of registration renewals for N users is N/TM 1007 since every renewal period, each user send out one renewal request. 1009 Now consider a system based on HAWAII. The domain root router, which 1010 houses the home agent, is the most heavily loaded router in this 1011 system as it has to process both path setup messages as well as 1012 Mobile-IP messages. The rate of Mobile-IP registrations, which occur 1013 only when user cross domain boundaries, is f(LD). The rate of 1014 Mobile-IP registration renewals, which are sent by only those users 1015 that are away from their home domain, is (Z*N)/TM. Path setup updates 1016 at the domain root router are generated whenever a user is handed off 1017 between base stations attached to two different second level routers. 1018 Thus, the rate of path setup updates is f(LR)*R. Path setup refreshes 1019 are aggregates, generated for each user. Thus, the rate of path 1020 setup refreshes is (Ceiling(N/Y)/TR). 1022 Table 2: Frequency of Mobility related messages (per second) 1023 -------------------------------------------------------------------- 1024 Type HAWAII at Domain Root Router Mobile-IP at Home Agent 1025 -------------------------------------------------------------------- 1026 HAWAII update 127.8 0 1027 HAWAII refresh 51.3 0 1028 Mobile-IP registration 48.4 574 1029 Mobile-IP renewals 12.7 127.4 1030 -------------------------------------------------------------------- 1031 Total 240.2 701.4 1032 -------------------------------------------------------------------- 1034 The frequency of various mobility related messages for the 1035 configuration shown in Table 1 is summarized in Table 2. The total 1036 number of control messages received by a HA in Mobile-IP (701.4) is 1037 almost three times the number of messages received by a domain root 1038 router in HAWAII (240.2). 1040 5.2 Quality of Service Support 1042 The fact that HAWAII maintains the IP address of the mobile host 1043 unchanged within a domain even as it moves simplifies the provision 1044 of flow-based QoS. In this section, we illustrate the ease with which 1045 the well-known resource reservation protocol, RSVP [17], is 1046 integrated with HAWAII. 1048 ________________ 1049 |CORRESPONDENT |--- 1050 |HOST AS SENDER | | 1051 |________________| ~ 1052 IP:2.2.1.1 ~ [1.1.1.1->C]*** 1 1053 | * Asynchronous 1054 --------- v notification 1055 | A | {DEST, PHOP, NHOP} 1056 ROUTER 0 | | {(0):1.1.1.1,A,B} 1057 | B C | {(7):1.1.1.1,A,C} 1058 ------+--<+++++ 1059 / @ \ + 1060 / @ \ + 7 1061 / 2 @ \ + 1062 / v \ + 1063 ROUTER 1--------- --------- ROUTER 2 1064 | A | | A | 1065 [1.1.1.1->A] | | | | [1.1.1.1->B] 1066 | B C | | B C | 1067 --------- --------- {DEST, PHOP, NHOP} 1068 | @ | ^ {(2):1.1.1.1,A,-} 1069 | 3 @ | + 6 {(6):1.1.1.1,A,B} 1070 | @ | + 1071 | v | + 1072 OLD BS ----- ----- NEW BS 1073 / A \ / A \ 1074 | | | | 1075 [1.1.1.1->A] \ B / \ B / [1.1.1.1->B] 1076 ----- 4 @-^-- 1077 @@@@@@@ + {DEST, PHOP, NHOP} 1078 @ + 5 {(3):1.1.1.1,A,-} 1079 --v- ++++++ {(5):1.1.1.1,A,B} 1080 MOBILE HOST / \ 1081 AS RECEIVER \ / @@@@@> PATH 1082 ---- +++++> RESV 1083 IP:1.1.1.1 1085 Figure 9: RSVP flows when mobile host is a receiver 1087 RSVP inherently assumes that hosts have fixed addresses, which is 1088 usually not the case for mobile hosts. When using Mobile-IP, the 1089 mobile host's home address is fixed, but its care-of-address changes. 1090 Since RSVP uses the destination address of the end node, i.e. the 1091 mobile host, for identifying a session, one has to redo the resource 1092 reservation along the entire path from the correspondent host (or HA) 1093 to the mobile host on every handoff of the mobile user. This must be 1094 performed even though most of the path is probably unchanged, as 1095 handoff is a local phenomenon. This results in increased reservation 1096 restoration latency and unnecessary control traffic. 1098 In the case of HAWAII, support for QoS is straightforward since a 1099 mobile host's address remains unchanged as long as the user remains 1100 within a domain. The interaction between HAWAII and RSVP when the 1101 mobile host is a receiver is shown in Figure 9. The state in the 1102 square braces represents HAWAII forwarding state while the state in 1103 the curly braces represents RSVP state. After Router 0 processes a 1104 HAWAII path setup update, its RSVP daemon receives a path change 1105 notification (PCN) (message 1) using the routing interface for 1106 RSVP [16]. In standard RSVP, the router must now wait a time 1107 interval before generating the RSVP PATH message to allow the route 1108 to stabilize; this time interval is set to two seconds by default. 1109 In HAWAII, the RSVP PATH message (message 2) can be triggered 1110 immediately on receiving a PCN since the route to the mobile host is 1111 stable at that point. This allows for a faster reconfiguration due 1112 to mobility. The PATH message follows the new routing path (messages 1113 2 and 3), installing PATH state on all the routers towards the new 1114 base station. When this PATH message reaches the mobile host, a QoS 1115 agent on the host generates an RSVP RESV message upstream that 1116 follows the reverse forwarding path (messages 5, 6, and 7). Router 0 1117 stops forwarding the RESV messages upstream since there is no change 1118 in the reservation state to be forwarded. Thus, reservations are 1119 restored locally in a timely manner. The case when the mobile host 1120 is a sender is fairly simple. A RSVP PATH message is sent by the 1121 mobile host after handoff as soon as the HAWAII path setup is 1122 complete, resulting in reservations along the new path. 1124 Note that the straightforward integration of RSVP and HAWAII is due 1125 to the fact that RSVP was designed to blindly follow the routing path 1126 established and maintained by an independent routing entity. The 1127 HAWAII path setup messages for a mobile host handoff are no different 1128 from any other routing changes to which RSVP was designed to respond. 1129 Thus, intra-domain handoffs in HAWAII are handled efficiently; since 1130 they are localized, they result in fast reservation restorations for 1131 the mobile user. In the case of inter-domain handoffs, since HAWAII 1132 defaults to Mobile-IP for mobility management, reservation 1133 restorations would follow along the procedures elaborated by the 1134 Mobile-IP working group. 1136 5.3 Reliability 1138 Failure of Home Agents is a concern for any approach that is based on 1139 Mobile-IP. In HAWAII as well as Mobile-IP, this failure could be 1140 tackled through the configuration and advertisement of backup home 1141 agents. Other approaches that rely on hot backups are also possible. 1142 However, recall that in HAWAII, in the common case of a mobile host 1143 not leaving its ``home'' domain, there is no HA involved. This 1144 greatly reduces HAWAII's vulnerability to HA failure as compared to 1145 the Mobile-IP schemes. 1147 Link and router failures are handled through the soft-state refresh 1148 mechanism in HAWAII. A standard routing daemon, such as RIP or OSPF, 1149 running at each router would detect these failures and update its 1150 default route entry. This will trigger an immediate soft-state 1151 refresh of all its host entries to a new uplink router (see Figure 8 1152 for details). This will result in further propagation of soft-state 1153 refresh messages until a router that has pre-existing entries for the 1154 affected mobile hosts is notified (this will be the domain root 1155 router in the worst case). Note that failures of domain root routers 1156 are also handled similarly; the one difference is that inter-domain 1157 routing protocols such as BGP will also be involved in order to 1158 redirect packets from outside the domain to a different domain root 1159 router. Thus, reliability is achieved through maintaining soft-state 1160 forwarding entries for the mobile hosts and leveraging fault 1161 detection mechanisms built in existing intra-domain routing 1162 protocols. 1164 As in any wireless system, in HAWAII, base station failures results 1165 in loss of connectivity to mobile users served by it. 1167 Finally, we need to address the issue of failure of HAWAII process 1168 itself without an accompanying router failure. To recover, the 1169 HAWAII process must simply be restarted as the subsequent soft-state 1170 refreshes correct the existing state. This may be addressed by 1171 several means. For instance, a process monitor resident in the same 1172 router as the HAWAII process could issue a restart upon detecting a 1173 non-responsive process. 1175 6 Address Assignment 1177 So far we have not made specific assumptions about how each mobile 1178 host acquires its IP addresses. In particular, we do not assume any 1179 correlation between the domain topology hierarchy and the actual 1180 address assignments to mobile hosts. Instead, we assume a flat 1181 address assignment algorithm in the domain. To put it another way, 1182 mobile hosts are assigned the next available address in the domain 1183 when they request one. 1185 Recall that, in HAWAII, each host potentially needs two IP addresses: 1186 one to operate in its home domain, and (possibly) a second when it 1187 moves outside its home domain. The address used by the mobile host 1188 in its home domain can be statically or dynamically assigned. We 1189 explore each of these options in the following paragraphs. Note that 1190 the co-located address used by the mobile host outside its home 1191 domain will always be dynamically assigned. 1193 If a mobile host is given its home address via manual configuration, 1194 when it moves outside its home domain, it has to either acquire a 1195 co-located care-of-address for itself or use a FA care-of address in 1196 the new domain, and act as a ``vanilla'' mobile-IP agent. If it 1197 acquires a co-located address, the benefits of HAWAII will be 1198 directly applicable. On the other hand, if the mobile host uses a FA 1199 terminated address, then the mobile host acts as a basic Mobile-IP 1200 client, potentially foregoing the advantages of HAWAII. 1202 The second option is to acquire both the home address and the 1203 co-located care-of-address through DHCP [6]. The mobile can retain 1204 the home address for the duration of its lifetime; we call this the 1205 quasi-permanent address of the mobile. This domain also becomes the 1206 mobile host's home domain. Because mobile hosts typically act as 1207 clients, as they activate applications, their servers will learn 1208 their IP addresses. If the mobile host moves into a different domain 1209 while powered up, it is assigned a second IP address through DHCP in 1210 the new domain. This address becomes the mobile host's co-located 1211 care-of address. The mobile host still retains the quasi permanent 1212 address assigned in its home network, and packets are tunneled 1213 to/from a home agent in its home network to its current location. In 1214 this way, mobility is transparent to the corresponding servers and 1215 applications. When the host is powered down, it gives back all its 1216 assigned addresses (permanent address and care-of address, if any). 1218 This requires modifying the client side of DHCP so that the client 1219 maintains leasing relationships with two different DHCP servers at 1220 the same time. The exact nature of this modification and its 1221 implications to DHCP are outside the scope of this specification. 1223 The use of a quasi permanent address is similar to the ``dialup'' 1224 model of service provided by Internet Service Providers to fixed 1225 hosts. The difference is that the users in HAWAII are mobile and the 1226 home domain is determined by where the host is powered up rather than 1227 which modem access number is dialed. Apart from requiring fewer IP 1228 addresses, this optimization also results in optimal routing as long 1229 as the user does not move out of a domain while powered up. 1231 7 Interactions between Mobile IP HA and 1233 HAWAII 1235 Many a dragon hides in the complexities of multi-protocol 1236 interaction. HAWAII and Mobile IP operate in parallel at the domain 1237 root router to track the inter-domain mobility of the host. 1239 Recall that, in HAWAII, the domain root router acts as the HA for 1240 hosts that are in a foreign domain. Therefore, HAWAII processing is 1241 required if the host is within the domain, and Mobile IP processing 1242 when it is roaming in a foreign domain. The protocols should 1243 coordinate with each other to maintain forwarding entries for the 1244 mobile host, so that interleaved arrival of protocol messages do not 1245 leave the forwarding tables in an inconsistent state. 1247 After the domain root router has processed the Mobile IP registration 1248 message, indicating that the host has moved from its home to a 1249 foreign domain, HAWAII must ignore refresh messages for this host 1250 from downstream routers; these are stale refresh messages and will 1251 eventually be timed out. Similarly, when the host has moved back 1252 from the foreign domain to its home domain, the domain root router 1253 should process the HAWAII update; however, Mobile IP should process 1254 any subsequent deregistration messages from the host only to remove 1255 its internal state, without affecting the forwarding entries. 1257 Another issue is that Mobile IP requires the home agent to add proxy 1258 arp entries for those mobile hosts that are in the foreign domain, 1259 and remove them when it receives an explicit deregistration message. 1260 The HA on the domain root router need not set such arp entries, since 1261 data packets will reach the domain root router based on the address 1262 allocation architecture of HAWAII. Moreover, such arp entries could 1263 interfere with connectivity when the host revisits its home domain; 1264 if the Mobile IP deregistration message is lost, the arp entry causes 1265 packets to be encapsulated and forwarded to the previous foreign 1266 domain by the HA. Thus, no packets can be sent to the mobile host 1267 until the Mobile IP state is removed following a timeout. Hence, the 1268 home agent on the domain root router must disable its proxy arp 1269 processing as these are unnecessary when the host is in a foreign 1270 domain, and will interfere with HAWAII processing when the host 1271 revisits its home domain. In the former case, all data packets for 1272 the mobile already traverse the domain root router, and can be 1273 forwarded to the mobile host. When the host revisits its home 1274 domain, if the Mobile IP deregistration message is either lost or was 1275 never sent, the arp entry causes packets to the host to be 1276 encapsulated and forwarded to the previous foreign domain by the 1277 Mobile IP home agent. Thus, no packets, including HAWAII 1278 acknowledgements, can be sent to the mobile host until the Mobile IP 1279 state is removed following a timeout. Hence, the home agent on the 1280 domain root router should disable its proxy arp processing. 1282 8 Security 1284 There are two issues in security: user authentication by the DHCP 1285 server during address assignment that occurs during power up and 1286 inter-domain moves; and security and authentication related to 1287 Mobile-IP and HAWAII protocol messages. 1289 This document does not specify solutions for addressing the security 1290 issues related to DHCP server authentication of a mobile user. 1291 Mechanisms such as the RADIUS protocol [15] could be used to perform 1292 the authentication. 1294 Regarding Mobile-IP messages, we assume a trust model and postulate 1295 the existence of a security infrastructure similar to the ones 1296 assumed in [4] and [14]. In particular, mobile-hosts must be able to 1297 trust registration replies generated by foreign agents, without the 1298 intervention of the home agent; also, home agents must be able to 1299 trust registrations generated by foreign agents, without the 1300 intervention of the mobile-host. This assumes the existence of a a 1301 verification and key-management infrastructure, to distribute 1302 temporary session-keys to the mobile host, the foreign-agents and the 1303 home-agent. In addition, the same infrastructure would serve the 1304 purpose to verify that a particular set of base stations is allowed 1305 by a HA to serve its mobile-hosts. All the protocol messages and the 1306 mechanisms to perform key distribution, identity verification and 1307 authorization are not explained in this document. However, refer 1308 to [2] and [3] for an example of a protocol capable of carrying out 1309 such operations. 1311 Authentication of HAWAII protocol messages is not a difficult issue 1312 since these messages are generated and processed only by nodes within 1313 a single administrative domain. A simple approach such as a password 1314 field as used in the Routing Information Protocols [8] can be used if 1315 necessary. 1317 Appendix A - Patent Issues 1319 This is to inform you that Lucent Technologies has applied for and/or 1320 has patent(s) that relates to the attached submission. 1322 This submission is being made pursuant to the provisions of IETF IPR 1323 Policy, RFC 2026, Sections 10.3.1 and 10.3.2. 1325 Lucent Technologies Inc. will offer patent licenses for submissions 1326 made by it which are adopted as a standard by your organization as 1327 follows: 1329 If part(s) of a submission by Lucent is included in a standard and 1330 Lucent has patents and/or pending applications that are essential 1331 to implementation of the included part(s) in said standard, Lucent 1332 is prepared to grant - on the basis of reciprocity (grantback) - a 1333 license on such included part(s) on reasonable, non-discriminatory 1334 terms and conditions. 1336 References 1338 [1] B. Aboba and M. A. Beadles, ``The network access identifier,'' 1339 Internet draft, Work in Progress, Nov 1998. 1341 [2] P. Calhoun and C.E. Perkins, ``DIAMETER Mobile IP Extensions,'' 1342 Internet draft, Work in Progress, Nov 1998. 1344 [3] P. Calhoun and A. Rubens, ``DIAMETER Base Protocol,'' Internet 1345 draft, Work in Progress, Nov 1998. 1347 [4] P. Calhoun, G. Montenegro, and C. E. Perkins, ``Mobile IP 1348 Regionalized Tunnel Management,'' Internet draft, Work in 1349 Progress, Nov 1998. 1351 [5] P. Calhoun and C.E. Perkins, ``Mobile IP Network Access 1352 Identifier Extension," Internet Draft, Work in Progress, May 1353 1999. 1355 [6] R. Droms, `` Dynamic Host Configuration Protocol,'' Request for 1356 Comments 2131, Mar 1997. 1358 [7] D. Johnson and C. Perkins, ``Mobility Support in IPv6,'' Internet 1359 Draft, Work in Progress, Nov 1998. 1361 [8] G. Malkin, ``RIP Version 2 Carrying Additional Information,'' 1362 Request for Comments 1723, Nov 1994. 1364 [9] D. Mills, "Network Time Protocol (Version 3): Specification, 1365 Implementation and Analysis", RFC 1305, Mar 1992. 1367 [10] S. Mohan and R. Jain, ``Two User Location Strategies for Personal 1368 Communications Services,'' IEEE Personal Communications, Vol 1., 1369 No. 1, pp. 42-50. 1371 [11] C.E. Perkins, ``IP Mobility Support,'' Request for Comments 2002, 1372 Oct 1996. 1374 [12] C.E. Perkins, and D.B. Johnson, ``Route Optimization in Mobile 1375 IP,'' Internet Draft, November 1997. 1377 [13] C.E. Perkins and D. Johnson, "Registration keys for route 1378 optimization," Internet Draft, December 1997. 1380 [14] C.E. Perkins and P. Calhoun, ``Mobile IP Challenge/Response 1381 Extensions," Internet Draft, Work in Progress, May 1999. 1383 [15] C. Rigney, A. Rubens, W. Simpson, and S. Willens, ``Remote 1384 Authentication Dial in User Service (RADIUS),'' Request for 1385 Comments 2138, Apr 1997. 1387 [16] D. Zappala and J. Kann., "RSRR: A Routing Interface for RSVP", 1389 [17] B. Braden et. al., ``Resource Reservation Protocol (RSVP) - 1390 Version 1 Functional Specification,'' Request for Comments 2205, 1391 Sep 1997. 1393 Authors' Addresses 1395 R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli 1396 Bell Labs, Lucent Technologies, 1397 101 Crawfords Corner Road, 1398 Holmdel, NJ 07733 (USA) 1399 Phone: 732-949-3306 1400 Fax: 732-949-4513 1401 Email: {ramjee,tlp,thuel,kvaradhan,lsalgarelli}@bell-labs.com