idnits 2.17.1 draft-castelluccia-uhmm-framework-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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.1 Overview' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 102 has weird spacing: '...ke sure that...' == Line 104 has weird spacing: '... of the mobil...' == Line 172 has weird spacing: '...routers that ...' == Line 413 has weird spacing: '... it is prefe...' == Line 523 has weird spacing: '...rwarded to...' -- 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 (25 June 1999) is 9069 days in the past. Is this intentional? 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: 'Cast98' on line 403 -- Looks like a reference, but probably isn't: 'CellIP' on line 612 == Unused Reference: '2' is defined on line 699, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2002 (ref. '2') (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-01) exists of draft-valko-cellularip-00 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Claude Castelluccia 2 INTERNET-DRAFT Lubovic Bellier 3 INRIA, FRANCE 4 25 June 1999 6 Toward a Unified Hierarchical Mobility Management Framework 7 draft-castelluccia-uhmm-framework-00.txt 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 other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 As the number of Mobile Nodes increases in the Internet, it becomes 32 clear that a hierarchical mobility management protocol is necessary. 33 The macro-mobility is the mobility between domains. The micro- 34 mobility is the mobility within one domain. Several proposals that 35 separate macro and micro-mobility has been proposed recently 36 (CellularIP[4], HAWAI[3], HMIP[1],...). 38 All these proposals agree that Mobile IP is suitable to handle 39 macro-mobility (inter-domain mobility) but they all propose a 40 different micro-mobility scheme. As a result, a Mobile Node won't be 41 able to roam seamlessly if it does not understand the different 42 micro-mobility management protocols of the domain that it visits. 44 In this document, we present a framework that allows the deployment 45 of various micro-mobility management protocols in different parts of 46 the Internet while still providing connectivity to Mobile Nodes. 48 We propose to decompose the Internet mobility management protocol 49 into three components. The first one, the access protocol, specifies 50 the registration procedures between the Mobile Node and the domain it 51 is attached to. It is standard and unique. The second one, the 52 micro-mobility protocol, manages local mobility and varies from one 53 domain to another. The third one, the macro-mobility protocol, 54 manages mobility across domains. We suggest to use Mobile IP as the 55 macro-mobility protocol. 57 This Internet Draft first describes the architecture of the proposed 58 framework. It then show how micro-Mobile IP and Cellular IP could be 59 deployed within this framework. 61 1- Introduction 63 There have been several hierarchical and cellular Mobile IP proposals 64 recently. This shows a huge interest for a scalable mobility 65 management scheme. There are at least 3 proposals that we know of : 66 - Ericsson/Columbia Cellular IP [4] 67 (http://comet.ctr.columbia.edu/cellularip/) 68 - Lucent HAWAII [3] (http://www.bell- 69 labs.com/user/ramjee/papers/draft-ramjee-micro-mobility-hawaii- 70 00.txt) 71 - INRIA HMIPv6 [1] 72 (http://sirac.inrialpes.fr/Infos/Personnes/Claude.Castelluccia/hmip.ps.gz) 74 All these proposals agree that Mobile IP is suitable to handle 75 macro-mobility, but they all propose a different micro-mobility 76 scheme. 78 From then, 2 directions are possible : 80 1- define a single micro-mobility protocol is defined and 81 standardized from the existing and forthcoming proposals. 83 2- define a framework that allows each proposal to be deployed and 84 that provides inter-operability is defined. 86 We argue that the second solution is preferable for the following 87 reasons. First we believe that there is probably not an "optimal" 88 micro-mobility scheme for every network. Different protocols might be 89 necessary for different networks' needs. Second, defining an open 90 system leads to more competition and flexibility. Each network 91 operator is then free to deploy its own micro-mobility protocol (and 92 to patent it:-)). New protocols can be deployed very easily. Last 93 but not least it eases drastically the standardization process ; the 94 different proposals do not have to be merged into a single one. 96 In this document, we propose a framework that allows the deployment 97 of different micro-mobility proposals. We assume that Mobile IP is 98 used as the macro-mobility protocol. 100 Our final goal is to define a framework that allows a Mobile Node to 101 roam seamlessly from one network to another, from one domain to 102 another... One condition to achieve this goal is to make sure that 103 the mobility management procedures performed by the Mobile Nodes are 104 independent of the mobility management protocols used in the core of 105 the network. 107 2- General concepts 109 In this document, we define a domain as an arbitrary structure. A 110 domain can be an ISP network, a campus network, a company network, a 111 set of LANs or even a single LAN. A domain is connected to the rest 112 of the Internet via one or several interconnection routers that we 113 call Border Routers in this document. 115 Our proposal differentiates the macro (inter-domain) mobility from 116 the micro (intra-domain) mobility. As a result, a host communicating 117 with a Mobile Node is only aware of its inter-domain mobility. The 118 Mobile Node's intra-domain mobility is completely hidden. It also 119 defines a standard Mobile Node registration protocol that is 120 independent of the mobility management protocols used in the core 121 network. As a result, different mobility management protocols can be 122 used in the different parts of the Internet while still providing 123 connectivity to the Mobile Node Hosts. 125 We propose a mobility management framework that uses Mobile IP for 126 inter-domain mobility but allows the deployment of any micro-mobility 127 protocol. As a matter a result, different domains can deploy 128 different micro-mobility protocols. 130 2.1 Design Goals/Constraints 132 The goals of our work is to propose a hierarchical mobility 133 management that : 135 1- does not require any modifications at the Correspondent Nodes 136 (Correspondent Nodes are running Mobile IP). 137 2- allows the deployment of different micro-mobility schemes 138 transparently to the Correspondent Nodes and the Mobile Nodes. 139 3- does not degrade routing performance. 140 4- is as secure as Mobile IP. 141 6- works in IPv4 and IPv6. 142 7- is power-efficient (i.e. minimizes the power). 144 2.2 Conceptual Model 146 In the proposed framework, the mobility management protocol is 147 composed of three components as illustrated in Figure 1. 149 - The first one, the access mobility management protocol, 150 specifies the registration procedures between the Mobile Node and 151 the domain it is attached to. It is standard and independent of 152 the micro and macro-mobility management protocols used in the core 153 of the network. This protocol is ``light'', i.e. minimises the 154 operations performed by the Mobile Node Hosts (which probably have 155 limited capacity and power). 157 - The second one, the micro-mobility management protocol, is the 158 protocol that handles the local mobility (within the domain) of 159 the Mobile Node. 161 - The third one, the macro-mobility management protocol, is the 162 protocol that handles the macro-mobility (inter-domain) of the 163 Mobile Node. We propose to use Mobile IP as macro-mobility 164 management protocol. 166 3- Proposed Framework 168 3.1 Overview 170 Our proposal is based on the deployment of Mobility Supports. 172 A Mobility Support is a router or a set of routers that maintains 173 a binding per Mobile Nodes currently visiting the domain. The 174 Mobility Support plays a central role in our proposal. It is 175 involved in the macro and micro-mobility management. For example, 176 the Mobility Support sends Binding Updates on behalf of the Mobile 177 Nodes it is serving (macro-mobility management). It also 178 intercepts packets addressed to the Mobile Nodes it is serving and 179 is in charge of redirecting them to their current location 180 (micro-mobility management). 182 Note that there is no constraint on the physical location of the 183 Mobility Support. However for efficiency reasons, it is 184 preferable to connect it as close as possible to the border router 185 of the network that it is serving. 187 In our proposal, the Mobile Node registration protocol is unique 188 and independent of the micro-mobility management protocol of the 189 domain. The nature and the position of the Mobility Support 190 depend on the micro-mobility management protocol. The only 191 requirements that we impose on the Mobility Support are : 193 (1) it must process registration messages coming from the Mobile 194 Nodes (the processing depends of the micro-mobility protocols), 196 (2) it must send Mobile IP Binding Updates to the Mobile Node's 197 Home Agent and Correspondent Nodes (according to the Mobile Node 198 IP specification) and 200 (3) it must intercept and redirect the packets addressed to the 201 Mobile Nodes (the way packets are forwarded to the Mobile Node 202 Hosts depends of the local micro-mobility protocol. 204 _____Domain________ ____Internet______ __ 205 / \ / \--|HA| 206 ------- | Mobility Support | ___ | | -- 207 |Mobile |---| O |_|BR |_| | 208 ------- | | | --- | | __ 209 | \__________|_______/ \__________________/--|CH| 210 | | -- 211 |===============>|<===========================================> 212 access protocol macro-mobility:Mobile IP 214 Figure1 : Registration 216 _____Domain_______ ____Internet______ __ 217 / \ / \--|HA| 218 ------- | Mobility Support | ___ | | -- 219 |Mobile |---| O |_|BR |_| | 220 ------- | | | --- | | __ 221 | \__________|________/ \___________________/--|CH| 222 | | -- 223 |<============== |<======================================== 224 micro-mobility macro-mobility:Mobile IP 226 Figure2 : Packet delivery 228 In summary, 229 1- the protocol between the Mobile Node and the Mobility Support is 230 unique 231 2- the intra-domain mobility management and routing is managed by the 232 local micro-mobility management protocol 233 3- the inter-domain mobility and routing is managed by Mobile IP 235 3.2 Main operations 237 The main operations of the proposed architecture are the following 238 : 240 3.2.1 Common operations : the Mobile Node-Mobility Support 241 registration 243 When the Mobile Node detects a new Base Station, it gets a CoA 244 (we call it PCoA, for Physical Care-of Address) and registers 245 to the Mobility Support. This registration is performed by 246 sending a (Home Address, Home Agent, PCoA, MS_p), where MS_p is 247 the Mobility Support of the Mobile Node in the previous domain. 248 This registration is acknowledged by the Mobility Support. 250 This registration phase is independent of the type of movement 251 (inter or intra-domain). 253 3.2.2 Inter-domain movement 255 When a Mobile Node moves into a new domain, it registers to the 256 new Mobility Support and the Mobility Support performs the 257 following registration operations : 259 3.2.2.1 Macro-mobility registration : 261 Upon reception of a registration message from a Mobile Node, 262 the Mobility Support must : 264 * get a VCoA (Virtual CoA-this could be the Mobility 265 Support's address or an address on its subnet) for the 266 Mobile Node and registers it to its Home Agent on behalf of 267 the Mobile Node. This Binding Update must be acknowledged. 268 This acknowledgement is forwarded to the Mobile Node. 270 * acknowledge the reception of the Mobile Node-Mobility 271 Support registration message to the Mobile Node (this 272 acknowlegement contains the VCoA). 274 * ask the previous Mobility Support (the Mobility Support of 275 the previous domain. We note it MS_p) to redirect all 276 packets addressed to the Mobile Node to it. MS_p must 277 acknowledge this request and send the list of current 278 Correspondent Nodes and the list of the sequence numbers of 279 the latest Binding Updates sent. 281 * create a entry that contains the binding between the 282 Mobile Node's Home address, its home agent and its VCoA + 283 list of (Correspondent Nodes, Sequence Numbers). 285 * send a (Home Address, VCoA) Binding Update to each 286 Correspondent Node. 288 Note : a Mobile Node must receive two ackowledgements after an 289 inter-domain movement : one from its Home Agent and one from 290 its current Mobility Support otherwise it must assume that the 291 registration has failed. 293 Upon reception of packets coming from the Home Agent or from 294 the previous Mobility Support, the new Mobility Support sends 295 Binding Updates to the Mobile Node's Correspondent Nodes. These 296 Binding Updates contain the Mobile Node's PCoA if the 297 Correspondent Node is local (i.e. within the visiting domain) 298 or the Mobile Node's VCoA if the Correspondent Node is distant 299 (outside the visiting domain). 301 3.2.2.2 Micro-mobility registration : 303 Upon reception of a registration message from a Mobile Node, 304 the Mobility Support must : 306 * create a entry that contains the binding between the 307 Mobile Node's PCoA and VCoA. This information is used by the 308 Mobility Support to redirect the packets addressed to the 309 Mobile Node (VCoA) to its current point of attachment 310 (PCoA). 312 3.2.3 Intra-domain movement : 314 When a Mobile Node moves within a domain (i.e it changes of Base 315 Station and/or subnet), the Mobile Node registers its new point of 316 attachement to the Mobility Support. The Mobility Support then 317 performs the following operations : 319 - macro-mobility registration 321 * no operation is required. 323 - micro-mobility registration 324 Upon reception of a registration message from the Mobile Node, 325 the Mobility Support : 327 * updates the corresponding entry in its cache, 329 * possibly sends Binding Updates to the Mobile Node's local 330 Correspondent Nodes. 332 Note that authentication is only necessary between the Mobile Node 333 and the Mobility Support, the Mobility Support and the Home Agent, 334 successive Mobility Supports, the Mobility Support and the 335 Correspondent Nodes. The Base Stations are just relays and 336 therefore do not need to be authenticated. 338 The Mobile Node must periodically send registration messages to 339 the Mobility Support to refresh its cache's entry. Identically the 340 Mobility Support must refresh the Mobile Node's VCoA to its Home 341 Agent and Correspondent Nodes by sending Binding Updates. 342 Note that the two refresh periods must not have the same value. 344 3.3 Packet delivery 346 When a (external) Correspondent Node first sends packets to a 347 Mobile Node, these packets are addressed to the Mobile Node's Home 348 address. These packets are intercepted by the Mobile Node's Home 349 Agent (if the Mobile Node is away) and forwarded (by 350 encapsulation) to the Mobile Node's current VCoA. The encapsulated 351 packets are intercepted by the Mobile Node's current Mobility 352 Support and forwarded to the current Mobile Node's PCoA. The 353 Mobility Support also sends a (Home Address, PCoA) or a (Home 354 Address, VCoA) Binding Update to the Correspondent Node according 355 to whether it is local or distant, and records the Correspondent 356 Node in its Mobile Node's list of Correspondent Nodes. 358 Upon reception of this Binding Update, the Correspondent Node 359 updates the Mobile Node's (Home Address, CoA) entry and sends the 360 forthcoming packets to the Mobile Node's new CoA. If the CoA is a 361 VCoA, the packets are intercepted by the Mobile Node's Mobility 362 Support and forwarded to the Mobile Node current PCoA. If the CoA 363 is a PCoA, the packets are routed directly to the Mobile Node's 364 current location. 366 Note that the forwarding method from the Mobility Support to the 367 Mobile Node's current PCoA is dependent of the micro-mobility 368 used in the domain. 370 When a Mobile Node sends a packet to a Correspondent Node, it must 371 include a HomeAddress option and use its VCoA as source address 372 (except if the Correspondent Node is local. In this case, it uses 373 its PCoA). 375 4 Examples 377 In this section, we describe in more details the architecture and 378 operations that are performed with different micro-mobility 379 management protocols. We consider two micro-mobility management 380 protocols namely micro-Mobile IP and Cellular IP. 382 4.1 Mobile Node - Mobility Support registrations 384 This phase is common to all micro-mobility proposals. 386 When the Mobile Node detects a Base Station, it possibly gets a 387 CoA (we call it, PCoA, for Physical Care-of Address) and 388 registers to the Mobility Server. This registration is performed 389 by sending a (Home address, Home Agent, PCoA, MS_p), where MS_p is 390 the previous Mobility Support of the Mobile Node. If the Mobile 391 Node did not change of Mobility Support, the MS_p field is then 392 set to Mobility Support. 394 The serving Mobility Support and the CoA is obtained via some kind 395 of DHCP server or auto-configuration mechanisms. Note also that 396 the Mobile Node's operations are independent of the mobility type 397 (whether is intra or inter-domain). 399 This registration must be acknowledged. 401 4.2 Micro-Mobile IP (uMIP) 403 The INRIA micro-Mobile IPv6 (uMIP) proposal [Cast98] is based on 404 the deployment of Mobility Networks.. A Mobile Network of a domain 405 is a LAN that defines an address space for the Mobile Nodes 406 roaming within this domain. A Mobility Network contains one or 407 several Mobility Supports. In uMIP, the Mobility Supports are 408 called Mobility Agents. A Mobility Agent is a router of the 409 Mobile Network that maintains a binding per Mobile Node currently 410 visiting the domain and sends Binding Updates on behalf of these 411 Mobile Nodes. Note that there is no constraint on the physical 412 location of the Mobility Network. However for efficiency reasons, 413 it is preferable to connect it to the border router of the 414 network that it is serving. The mobility Network can actually be 415 any sub-network of the domain. It does not have to be dedicated to 416 Mobile Nodes but instead can support ordinary (fixed) hosts. 418 Deploying a Mobility Agent in a separate Mobility Network instead 419 of implementing it on the Border Router has two main advantages. 421 First, it does not require any modification to the routers and is 422 therefore easier to deploy. Second, it is more scalable since (1) 423 it does not add additional processing constraints on the Border 424 Router and (2) several Mobility Agents could be deployed for 425 scalability and/or robustness motivations. However the Mobility 426 Agent can be implemented within the Border Router if this is 427 desirable. 429 The main operations of the uMIP proposal are the following. 431 4.2.1 Inter-domain mobility 433 When a Mobile Node moves into a new domain, the following 434 registrations are performed : 436 - Mobile Node - Mobile Support registration: 438 The Mobile Node registers to the Mobility Agent as described in 439 section 4.1. 441 - micro-mobility registration operations : Upon reception of a 442 registration message from a Mobile Node, the Mobility Agent : 444 o creates an entry that contains the binding between the 445 Mobile Node's PCoA and VCoA. This information is used by the 446 Mobility Agent to redirect the packets addressed to the 447 Mobile Node (VCoA) to its current point of attachment 448 (PCoA). 450 o sends a (Home Address, PCoA) to the domain's Correspondent 451 Nodes to optimize the Correspondent Node-Mobile Node 452 routing. 454 - macro-mobility registration operations (these operations is 455 actually independent of the micro-mobility protocol in used): 457 Upon reception of the Mobile Node-Mobility Support registration 458 message, the Mobility Agent : 460 * gets a VCoA (an address belonging to the Mobile Network) 461 for the Mobile Node and registers it to its Home Agent on 462 behalf of the Mobile Node. This Binding Update is 463 acknowledged by the Home Agent and forwarded to the Mobile 464 Node. 466 * acknowledges the reception of the Mobile Node-Mobility 467 Support registration message to the Mobile Node (this 468 acknowlegement contains the VCoA). 470 * asks the previous Mobility Agent to redirect all packets 471 addressed to the Mobile Node to it. The Previous Mobility 472 Agent acknowledges this request and sends the list of 473 current Correspondent Nodes and the sequence numbers of the 474 latest Binding Updates that were sent. 476 * creates an entry that contains the binding between the 477 Mobile Node's Home address, its home agent and its VCoA + 478 list of (Correspondent Nodes, Sequence numbers). 480 * sends a (Home Address, VCoA) Binding Update to each 481 Correspondent Node. 483 4.2.2 Intra-domain mobility : 485 When a Mobile Node moves within a domain (i.e it changes of 486 Base Station and/or subnet), the following registrations are 487 performed : 489 - Mobile Node-Mobility Support registration : see Section 4.1. 491 - macro-mobility : 493 * nothing is sent except the periodic registration refresh 494 messages. 496 - micro-mobility registration : 498 * The Mobility Agent updates the Mobile Node entry of its 499 cache. 501 * The Mobility Agent sends a (Home Address, PCoA) Binding 502 Update to each of the Mobile Node's local Correspondent 503 Nodes. 505 4.2.3 Packet delivery 507 When a (external) Correspondent Node first sends packets to a 508 Mobile Node, these packets are addressed to the Mobile Node's 509 Home address. These packets are intercepted by the Mobile 510 Node's Home Agent (if the Mobile Node is away) and forwarded 511 (by encapsulation) to the Mobile Node's current VCoA. The 512 encapsulated packets are intercepted by the Mobile Node's 513 current Mobility Agent and forwarded (via encapsulation) to the 514 current Mobile Node's PCoA. The Mobility Agent adds an entry in 515 its cache and sends a (Home Address, PCoA) or a (Home Address, 516 VCoA) Binding Update to the Correspondent Node according 517 whether it is local or distant. 519 Upon reception of this Binding Update, the Correspondent Node 520 updates the Mobile Node's binding(Home Address, CoA) entry and 521 sends the forthcoming packets to the Mobile Node's current 522 position. If the CoA is the Mobility Agent's address, the 523 packets are intercepted by the Mobility Agent and forwarded to 524 the Mobile Node current PCoA (via encapsultion). If the CoA is 525 a PCoA, the packets is routed directly to the Mobile Node's 526 current location... 528 4.3 Cellular IP 530 When Cellular IP is used as micro-mobility protocol, the Mobility 531 Support is located within the Border Router of the domain. The 532 VCoA assigned to the Mobile Nodes is the address of the Mobility 533 Support/Border Router. 535 The main operations of the proposed architecture are the following 536 : 538 4.3.1 Inter-domain movement 540 When a Mobile Node moves into a new domain, the following 541 registrations are performed : 543 - Mobile Node-Mobility Support registration : 545 The Mobile Node sends a registration message to the Mobility 546 Support (Border Router) as specified in 4.1. 548 - micro-mobility registration : 550 This registration message is intercepted by the Base Station, 551 the Mobile Node is attached to. The Base Station encapsulates 552 the message within a Route-Update packet as described in 553 [CellIP] and forwards it to the Border Router/Mobility Support. 554 The Route-Update packet creates and updates entries in each 555 node's cache from the Mobile Node to the Mobility Support. 557 This registration is acknowledged. (The current Mobility 558 Support is broadcast by the base stations using a router 559 advertissement). 561 - macro-mobility registration : 563 Upon reception of the Mobile Node-Mobility Support registration 564 message, the Mobility Support/Border Router : 566 * registers the Mobile Node to its Home Agent using its 567 address (the Mobility Support's address). This is performed 568 by sending a (Home Address, Mobility Support) Binding 569 Update. This Binding Update is acknowledged. The 570 acknowledgement is forwarded back to the Mobile Node's PCoA 571 (via the Cellular IP routing process). 573 * acknowledges the reception of the Mobile Node-Mobility 574 Support registration message to the Mobile Node (this 575 acknowlegement contains the VCoA). 577 * asks the previous Mobility Support (the Mobility Support 578 of the previous domain. We note it MS_p) to redirect all 579 packets addressed to the Mobile Node to it. MS_p 580 acknowledges this request and sends the list of current 581 Correspondent Nodes and the sequence numbers of the lattest 582 Binding Updates that were sent. 584 * creates a entry that contains the binding between the 585 Mobile Node's Home address, its home agent and its VCoA + 586 list of (Correspondent Nodes, Sequence Number). 588 * sends a (Home Address, VCoA) Binding Update to each 589 Correspondent Node. These Binding Updates contain the Mobile 590 Node's PCoA if the Correspondent Node is local (i.e. within 591 the visiting domain) or the Mobility Support/Border Router's 592 address if the Correspondent Node is distant (outside the 593 visiting domain). 595 4.3.2 Intra-domain movement : 597 When a Mobile Node moves within a domain (i.e it changes of 598 Base Station and/or subnet), the following registrations are 599 performed : 601 - Mobile Node-Mobility Support registration : 603 The Mobile Node sends a registration message to the Mobility 604 Support (Border Router) as specified in 4.1. 606 - micro-mobility 608 This registration message is intercepted by the Base Station, 609 the Mobile Node is attached to. The Base Station encapsulates 610 the message within a Route-Update packet as described in 612 [CellIP] and forwards it to the Border Router/Mobility Support. 614 The Route-Update packet creates and updates entries in each 615 node's cache from the Mobile Node to the Mobility Support. 617 - macro-mobility 619 No macro-mobility registration is necessary....besides the 620 regular Binding Update refresh Binding Update messages. 622 4.3.3 Packet delivery 624 When a (external) Correspondent Node first sends packets to a 625 Mobile Node, these packets are addressed to the Mobile Node's 626 Home address. These packets are intercepted by the Mobile 627 Node's Home Agent (if the Mobile Node is away) and forwarded 628 (by encapsulation) to the Mobile Node's current Mobility 629 Support/Border Router. The encapsulated packets are received by 630 the Mobile Node's current Mobility Support/Border Router, 631 decapsulated and forwarded (via the CellularIP routing 632 mechanisms) to the current Mobile Node's PCoA. The Mobility 633 Support/Border Router also sends a (Home Address, Border 634 Router) to the external Correspondent Nodes. 636 Upon reception of this Binding Update, the Correspondent Node 637 updates the Mobile Node's (Home Address, CoA) entry and sends 638 the forthcoming packets to the Mobile Node's current Mobility 639 Support. The packets are received by the Mobility Support, and 640 forwarded to the Mobile Node current PCoA. 642 5. Security Considerations 644 As in Mobile Node IP, all registration messages have to be 645 authenticated. As in Mobile Node IP, we propose to use IPSEC to 646 authenticate the registration messages and the binding updates. 648 There is two levels of security : 649 - The macro-mobility registration messages must be authenticated 650 between the Mobility Support and the Correspondent Nodes. 651 - The micro-mobility registration messages must be authenticated 652 between the Mobility Support and the Mobile Nodes. 654 Our proposal does not introduce more security problems that those 655 introduced by Mobile IP. 657 6. Conlusion 659 We propose a framework that allows the deployment of various micro- 660 mobility management protocols in different parts of the Internet 661 while still providing connectivity to Mobile Nodes. 663 In the proposed framework, the mobility management protocol is 664 composed of 3 components: 666 - The first one, the access mobility management protocol, 667 specifies the registration procedure between the Mobile Node and 668 the domain it is attached to. It is standard and independent of 669 the micro and macro-mobility management protocols used in the core 670 of the network. This protocol is ``light'', i.e. minimises the 671 operations performed by the Mobile Nodes (which probably have 672 limited capacity and power). 674 - The second one, the micro-mobility management protocol, is the 675 protocol that handles the local mobility (within the domain) of 676 the Mobile Node. 678 - The third one, the macro-mobility management protocol, is the 679 protocol that handles the macro-mobility (inter-domain) of the 680 Mobile Node. We propose to use Mobile IP as macro-mobility 681 management protocol. 683 The complete specification of these different components are on its 684 way and will be published soon. The access protocol uses Mobile IPv6 685 registration messages. 687 7. Acknowledgments 689 We would like to thank Imad Aad, Patrick Cipiere, Jean Michel 690 Combe, Walid Dabbous, Thomas Eklund, Thierry Ernst, Patrice Romand 691 and Aime LeRouzic for their valuable comments on this draft. 693 8. References 695 [1] Castelluccia C., "An Hierarchical Mobile IPv6 Proposal", INRIA 696 TR-0226, November 1998. Available at 697 http://www.inrialpes.fr/Planete/people/ccastel/index.html 699 [2] Perkins, C., Editor: "IP Mobility Support", RFC 2002, October 700 1996. 702 [3] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro- 703 mobility support using HAWAII", draft-ramjee-micro-mobility-hawaii- 704 00.txt, 19 February 1999. Work in progress. 706 [4] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet 707 draft, draft-valko-cellularip-00.txt, November 1998. Work in 708 progress. 710 Author's Address 712 Claude Castelluccia and Ludovic Bellier 713 INRIA 714 PLANETE team 715 ZIRST-655 avenue de l'Europe 716 38330 Montbonnot Saint Martin 717 FRANCE 719 Claude.Castelluccia@inria.fr 720 Ludovic.Bellier@inria.fr 722 draft-castelluccia-uhmm-framework-00.txt