idnits 2.17.1 draft-haddad-mipshop-omm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 946. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 17, 2005) is 6856 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) == Unused Reference: 'EAR' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'MIP6' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'NDIS' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'SEND' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'TERM' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 879, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-jinchoi-dna-frd-00 -- Possible downref: Normative reference to a draft: ref. 'EAR' == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-06 -- Possible downref: Normative reference to a draft: ref. 'ICMPv6' ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-hmipv6 (ref. 'HMIPv6') ** Obsolete normative reference: RFC 3775 (ref. 'MIP6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-01 -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in 'TERM'. ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: January 18, 2006 Ericsson Research 5 H. Soliman 6 Flarion 7 G. Daley 8 Monash University CTIE 9 H. Tschofenig 10 Siemens AG 11 July 17, 2005 13 Optimizing Micromobility Management for Active and Dormant Mobile Nodes 14 draft-haddad-mipshop-omm-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 18, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 Micromobility protocols address mobile nodes (MN) movements within a 48 particular IP network domain. This document introduces a new 49 protocol "Optimized Micromobility Management" (OMM), to manage 50 Micromobility for active and dormant mobile nodes. The suggested 51 solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal 52 and aims to increase the mobility performance by reducing the 53 handover latency and the packet loss. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . 4 59 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overview of HMIPv6 . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Problem, Motivation and Requirements . . . . . . . . . . . . . 9 62 6. Overview of the OMM Protocol . . . . . . . . . . . . . . . . . 11 63 7. OMM Protocol Description . . . . . . . . . . . . . . . . . . . 14 64 8. Mobility for Dormant Mode Mobile Nodes . . . . . . . . . . . . 17 65 9. OMM New Bits, Options and Messages Structure . . . . . . . . . 19 66 9.1 The Address Check Information Option (ACIO) . . . . . . . 19 67 9.2 The Optimized Micro-Mobility Information Option (OMMIO) . 19 68 9.3 Paging Zone Identifier Option (PZIO) . . . . . . . . . . . 20 69 9.4 The VMAP (V) Bit . . . . . . . . . . . . . . . . . . . . . 20 70 9.5 Modified Router Solicitation message format . . . . . . . 21 71 9.6 Modified Binding Acknowledgement message format . . . . . 22 72 9.7 The Routing Path Update (RPU) Message . . . . . . . . . . 22 73 9.8 The Location Update (LU) Message . . . . . . . . . . . . . 23 74 9.9 The Location Acknowledgement (LA) Message . . . . . . . . 23 75 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 77 12. Informative References . . . . . . . . . . . . . . . . . . . 26 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 80 Intellectual Property and Copyright Statements . . . . . . . . 28 82 1. Introduction 84 Managing Micromobility has been addressed in many different ways. 85 Among existing proposals (e.g., [HMIPv6], [CIP], [HAWAII], etc), only 86 the HMIPv6 proposal has been adopted by the IETF. 88 This document introduces a new protocol, i.e., OMM, to manage 89 Micromobility for active and dormant mobile nodes. The suggested 90 solution is entirely based on the Hierarchical Mobile IPv6 (HMIPv6) 91 proposal and aims to increase the mobility performance by reducing 92 the handover latency and packet loss. For these purposes, the OMM 93 protocol uses Virtual Mobility Anchor Points (VMAPs) and splits the 94 handover event into two successive phases triggered by the network 95 and the mobile node (MN). For dormant MNs, OMM uses the VMAP nodes 96 as Paging Agents (PA) and allows to page multiple MNs concurrently, 97 in order to optimize the bandwidth usage and minimize the call setup 98 delay. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Glossary 108 +---------------------+---------------------------------------------+ 109 | Term | Definition | 110 +---------------------+---------------------------------------------+ 111 | Mobility Anchor | A Mobility Anchor Point is a router located | 112 | Point (MAP) | in a network visited by the mobile node. | 113 | | One or more MAPs can exist within a visited | 114 | | domain. | 115 | | | 116 | Virtual MAP (VMAP) | A virtual MAP is a router located inside | 117 | | the IP network domain (i.e., a MAP is also | 118 | | a VMAP), which implements a set of | 119 | | features, which includes a subset of the | 120 | | MAP features. A VMAP node stores the MN's | 121 | | Regional Care-of Address (RCoA) and current | 122 | | Local Care-of Address (LCoA) for a limited | 123 | | period of time (e.g., the binding | 124 | | lifetime), computes the new MN's LCoA and | 125 | | encapsulates when needed data packets sent | 126 | | by the CN to the MN's current location. At | 127 | | any particular time during an ongoing | 128 | | session(s), the mobile node should have AT | 129 | | MOST one VMAP encapsulating data packets | 130 | | and fowarding them to its new current | 131 | | location. As mentioned earlier, each VMAP | 132 | | carries the PA functionalities and defines | 133 | | its own Paging Zone (PZ). | 134 | | | 135 | Access Router (AR) | The mobile node's default router. The AR | 136 | | aggregates the outbound traffic of mobile | 137 | | nodes. An AR can also be a MAP/VMAP. | 138 | | | 139 | Regional Care-of | An RCoA is an IPv6 address obtained by the | 140 | Address (RCoA) | mobile node from the visited network. An | 141 | | RCoA is an address on the MAP's subnet. It | 142 | | is auto-configured by the MN when receiving | 143 | | the MAP option. | 144 | | | 145 | On Link Care-of | The LCoA is the on-link CoA configured on a | 146 | Address (LCoA) | mobile node's interface based on the prefix | 147 | | is advertised by its default router. | 148 | | | 149 | Tree Architecture | An IP network domain has a tree | 150 | | architecture when any router located inside | 151 | | the domain (i.e., except the ARs and the | 152 | | root gateway(s)) has only one uplink and | 153 | | one or more downlink(s). Such topology has | 154 | | no mesh links. | 155 | | | 156 | Mesh Architecture | A mesh network topology is defined as a | 157 | | pure tree topology with additional mesh | 158 | | links. This means that in a mesh topology, | 159 | | at least one router located inside the | 160 | | domain has one or more mesh link(s) in | 161 | | addition to its uplink and downlink(s) | 162 | | channels. | 163 | | | 164 | Random Architecture | A random network topology is used to | 165 | | indicate a mesh topology with additional | 166 | | uplinks. This means that in a random | 167 | | topology, at least one router located | 168 | | inside the domain has more than one | 169 | | uplink(s), in addition to its downlink(s) | 170 | | and mesh link(s) channels. | 171 | | | 172 | Local Binding | The Mobile Node sends a Local Binding | 173 | Update (LBU) | Update (LBU) message to the MAP in order to | 174 | Message | establish a binding between the RCoA and | 175 | | the LCoA. | 176 | | | 177 | Routing Path Update | A Routing Path Update Message is sent by | 178 | (RPU) Message | the new MN's New Access Router to the MN's | 179 | | Previous LCoA (pLCoA). The RPU message is | 180 | | used to trigger a Network Handover, which | 181 | | is totally transparent to the MN. | 182 | | | 183 | Network Handover | A Network Handover can be defined in the | 184 | (NH) | context of the OMM protocol, as the process | 185 | | triggered by the network, of re-routing | 186 | | data packets flow(s) sent to a particular | 187 | | mobile node to its new location before the | 188 | | MN sends an LBU message to the MAP. The NH | 189 | | process aims to minimize the handover | 190 | | latency as well as the packet loss. | 191 | | | 192 | Dormant Mode | A state in which the mobile node restricts | 193 | | its ability to receive normal IP traffic by | 194 | | reducing monitoring of radio channels. This | 195 | | allows the mobile node to save power and | 196 | | reduces signaling load on the network. | 197 | Paging | As a consequence of a mobile-bound packet | 198 | | destined for a mobile currently in dormant | 199 | | mode, signaling by the network through | 200 | | radio access points directed to locating | 201 | | the mobile and alerting it to establish a | 202 | | last hop connection. | 203 | | | 204 | Paging Zone | A Paging Zone is the set of Access Points | 205 | | (APs) attached to one particular VMAP. Note | 206 | | that this definition applies only when the | 207 | | particular VMAP is an access router, which | 208 | | is the case in most random architecture. A | 209 | | mobile node in dormant mode may be required | 210 | | to signal to the network when it crosses a | 211 | | paging zone boundary, in order that the | 212 | | network network can maintain a rough idea | 213 | | of where the mobile is located. | 214 | | | 215 | Location Update | A Location Update Message is sent by the | 216 | (LU) Message | Paging Agent to the MAP to update it with | 217 | | the current Paging Zone of a particular MN | 218 | | while being in a dormant state. | 219 | | | 220 | Location | A Location Acknowledgment Message is sent | 221 | Acknowledgment (LA) | by the MAP to one particular VMAP to | 222 | Message | acknowledge the receipt of a Location | 223 | | Update Message sent earlier by the same | 224 | | VMAP. | 225 | | | 226 | Paging Message (PM) | A Paging Message is broadcasted by the VMAP | 227 | | to all mobile nodes located within its | 228 | | Paging Zone. The PM message carries among | 229 | | others, an 128-bits parameters representing | 230 | | the set of all targeted mobile nodes, and a | 231 | | set of hash functions, which allow all | 232 | | mobile nodes within the PZ to check if they | 233 | | belong to the set of the targeted nodes. | 234 +---------------------+---------------------------------------------+ 236 Table 1: Glossary 238 For more details about terms defined above, please refer to [HMIPv6], 239 [TOMOP] and [Paging]. 241 4. Overview of HMIPv6 243 The two main goals behind designing the [HMIPv6] protocol are to 244 reduce both the heavy amount of signaling messages generated by the 245 MIPv6 protocol and the handover latency. A third goal is to enable 246 the MN to hide its movements and current location from the CN and the 247 HA. 249 HMIPv6 consists on deploying one or more special nodes called 250 Mobility Anchor Point, i.e, MAP, within the IP network domain. A MAP 251 can be defined as a local home agent, which intercepts all packets 252 addressed to registered mobile nodes and tunnels them to the MN. 254 When a MN enters to an HMIPv6 domain, it starts by selecting, then 255 registering itself with the appropriate MAP. This is done by 256 processing special information sent by the MN's AR in the Router 257 Advertisement (RtAdv) message. These information allow the MN to 258 auto-configure a regional care-of address (RCoA), which will be used 259 by the MAP to capture packets sent from outside the domain to the 260 MN's care-of address (i.e., RCoA), and a link care-of address 261 (LCoA), which will be used by the MAP to locate the MN inside the MAP 262 domain. 264 It should be noted at this stage that HMIPv6 recommends that the MN 265 selects the furthest MAP to avoid frequent MAP changes, which in turn 266 implies going through the time consuming MAP registration procedure 267 during the handover. 269 Each time the MN moves to a new AR, it has to configure a new LCoA 270 and registers it with the MAP. This is done by sending a Local 271 Binding Update (LBU) message to the MAP. The LBU message allows the 272 MAP to bind the new LCoA to the MN's RCoA. 274 5. Problem, Motivation and Requirements 276 HMIPv6 protocol succeeds in eliminating redundant signaling messages 277 in MIPv6, i.e., the HoTI/HoT and CoTI/CoT messages, while keeping 278 only critical mobility messages, i.e., local binding update (LBU) and 279 binding acknowledgement (BA) messages, exchanged between the MN and 280 the MAP. 282 However, HMIPv6 partially succeeds in reducing the handover latency 283 since the LBU message sent from the MN to the MAP will most likely 284 have to travel on a relatively long path within the domain before 285 reaching the MAP (being supposedly static), in order to trigger a re- 286 routing of the data packets flow to the MN's new LCoA (nLCoA). Such 287 delay may result in packet loss, which becomes more alarming if the 288 MN is moving at a high speed within the MAP domain while running time 289 sensitive applications. 291 This is mainly due to the fact that HMIPv6 recommends avoiding 292 changing the MAP as much as possible. Consequently, HMIPv6 suggests 293 choosing the furthest MAP in the hierarchical domain, which is in 294 most cases the domain gateway node(s). 296 In addition, HMIPv6 practically converts any network topology (i.e., 297 mesh or random) to a tree topology, which if deployed alone, lacks 298 both robustness and load balancing features. 300 Based on that, HMIPv6 does not take any advantage from a mesh or 301 random topology since all signaling messages are sent on the shortest 302 uplink path to the root of the tree topology, i.e., the furthest MAP 303 gateway. 305 But it should be noted that HMIPv6 provides the lowest handover 306 latency among other micromobility proposals (e.g., HAWAII and CIP) 307 for the first handover only, i.e., when the MN enters into an HMIPv6 308 domain. But when the MN starts moving within the MAP domain then the 309 handover performance start decreasing when compared to the two other 310 proposals ([TOMOP], [MIPS]). 312 Note that, although the mobility performance may increase in both CIP 313 and HAWAII proposals, the CIP protocol continuously involves every 314 node on the path between the gateway and the MN, and requires being 315 implemented in the base station. On the other hand, the HAWAII 316 proposal relies on sub-optimal routing path(s), which in turn can 317 lead to an unoptimized load balancing in the access network. 319 Based on the above, the requirements for a new optimized micro- 320 mobility protocol, which offer the main advantages of each of the 321 above protocol, are: 323 a. The load of signaling messages required during the handoff 324 procedure should be minimized as much as possible. 326 b. In order to minimize or eliminate the handoff latency and packet 327 loss, the load of signaling messages should be concentrated only 328 near the involved MN's new AR. 330 c. As it is the case in HMIPv6, the handoff procedure should result 331 at the end in a new optimal path between the MAP and the new MN's 332 location. 334 d. Any new node in the MAP domain which may be involved in the 335 handoff procedure should be maintained in soft-state so that 336 invalid bindings/keys are deleted automatically. 338 e. All signaling Messages exchanged between routers and between 339 routers and the MAP are authenticated. 341 The above requirements led to the design of a simple proposal, which 342 is totally built on top of HMIPv6 and increases the performance of IP 343 handovers, which occur within an HMIPv6 domain. In addition, the OMM 344 protocol takes full advantage from a mesh/random topology. 346 6. Overview of the OMM Protocol 348 The OMM protocol aims to bring key advantages provided by some 349 existing micromobility proposals, like CIP, HAWAII and HMIPv6, while 350 minimizing/eliminating their different drawbacks. The OMM protocol 351 fulfills requirements a), b) and c) by adding at most one message 352 between the MN's nAR and one special node (i.e., VMAP) located 353 nearby. Moreover, the OMM protocol allows the MN to skip the DAD or, 354 in the worst case, to perform it in parallel with exchanging data. 356 In short, the OMM protocol splits the IP handover into two successive 357 events. The first one is a network handover (NH) and is triggered by 358 the infrastructure itself (i.e., the MN's new AR). Note that the NH 359 greatly benefits from a random network topology, i.e., it relies on 360 sub-optimal routing of data packets (as in HAWAII) sent to the MN, in 361 exchange for a shorter latency and minimum packets loss. 363 The main goals behind triggering first a network handover are to 364 reduce the latency and packet loss as much as possible. In other 365 words, the NH aims to eliminate the latency variable from the second 366 event, which is the handover triggered by the MN itself according to 367 HMIPv6 protocol. 369 For these purposes, the OMM protocol requires implementing a limited 370 set of the MAP features on routers located between the MAP and the 371 ARs, i.e., in order to convert them to VMAPs. Each time the MAP gets 372 an LBU message from the MN, it sends a BA message, which is used also 373 to store the MN's RCoA in the VMAP(s) located near the MN and on the 374 path between the MAP and the MN. Note that these signaling data are 375 stored in VMAP(s) in a soft state and must be removed immediatley 376 after the expiration of the Binding Update Lifetime set by the MN in 377 the LBU message. 379 Each time, the network infrastructure triggers a NH, the VMAP 380 simulates the MAP role for a limited period of time, i.e., until the 381 second event is completed, thus significantly reducing the latency 382 and packets loss. 384 It becomes clear from the above that, in order to get the best 385 performance from the NH, the selected VMAP must be located as close 386 as possible to the MN's new AR (or within the nAR itself depending on 387 the network topology). 389 In the OMM protocol, the second event, i.e., handover triggered by 390 the MN, aims only to re-direct data packets flow sent to the MN to a 391 more optimal path. Such step is needed, especially that the first 392 event, i.e., NH, may use a sub-optimal path to pull data packets flow 393 to the MN's new LCoA. As described in HMIPv6, the second event 394 updates the MAP BCE with the new MN's LCoA in order to allow the MAP 395 to tunnel data packets to the new MN's LCoA. 397 Finally, it should be noted that the worst case scenario in OMM 398 protocol is the failure of the NH, which means having only the 399 handover triggered by the MN itself, as defined in HMIPv6. This lead 400 us to the HMIPv6 case. 402 The following figure shows the VMAPs location in a full random 403 hierarchical domain topology: 405 +-----------+ 406 | MAP | 407 +-----------+ 408 / \ 409 / \ 410 / \ 411 +---+ +---+ 412 | R |.................| R | 413 +---+ # +---+ 414 / \ # / \ 415 / \ # / \ 416 +--+ +--+ # +--+ +--+ 417 |R |.........|R |.....|R |.........|R | 418 +--+# +--+ +--+ +--+ 419 / \ # / \ / \ / \ 420 +--+ +--+ #+--+ +--+ +--+ +--+ +--+ +--+ 421 |V |...|V |...|V |.|V |.|V |..|V |...|V |.|V | 422 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 423 ****** ****** **** **** **** **** ***** ***** 425 Where: 427 - R represents a router 429 - V reprsents a Virtual MAP (VMAP) 431 - ... represents a mesh link, i.e., mesh topology 433 - ### represents a random link, i.e., random topology 435 - * represents an AP 437 Note that having a full mesh topology only at the lowest level of the 438 hierarchical domain topology requires converting only the ARs to 439 VMAPs in order to obtain maximum performance. 441 7. OMM Protocol Description 443 As mentioned earlier, OMM protocol consists on implementing a limited 444 set of MAP features (and one new feature) in routers located between 445 the MAP and the ARs. A router with the added set of MAP features is 446 called a virtual MAP (VMAP). A VMAP enabled router MUST provide the 447 two following features: 449 o Store the MN's IPv6 addresses (i.e., RCoA and LCoA) in its Virtual 450 Binding Cache Entry (VBCE). This is performed upon receiving a BA 451 message carrying a binding hop-by-hop message. 453 o Check the ownership of the old MN's old LCoA (oLCoA), computes the 454 new MN's LCoA (nLCoA) and tunnel data packets sent to the MN's 455 nLCoA. This is performed upon receiving a Routing Path Update 456 (RPU) message. 458 The techniques proposed in this document work at their best when the 459 following conditions are met: 461 o The MAP domain has a random network topology. 463 o Messages exchanged between routers (i.e., VMAPs and ARs), located 464 within the same MAP domain are authenticated. 466 o All routers located in the same MAP domain can be converted to 467 VMAPs. This assumption applies also for the ARs. Note that this 468 is not a required condition. If there are no VMAPs on the path 469 between the nAR and the pLCoA the situation boils down to the base 470 HMIPv6 case. 472 However, it should be noted that adding links between ARs and 473 converting some or all of them to VMAPs can bring additional 474 performance to the OMM protocol and help avoiding updating all 475 exiting VMAPs located between the MAP and the MN each time the MN 476 switches to a new AR. 478 HMIPv6 protocol requires the ARs to add the MAP functions data to 479 their RtAdv messages sent to the MN. These information allow the MN 480 to select the furthest MAP, auto-configure an RCoA and an LCoA and 481 send them to the MAP in an LBU message. The two addresses enable the 482 MAP to create the binding and to intercept data packets sent to the 483 MN's RCoA and tunnel them to the MN's current location. 485 When the MN enters for the first time to an HMIPv6 domain, it MUST 486 follow the HMIPv6 protocol. The first new step introduced by the OMM 487 protocol consists on alerting the MN of the support for the OMM 488 protocol. This is done by setting the Optimization (O) bit (defined 489 in 8.10) in the RtAdv message sent by the AR. 491 The second step starts when the MAP sends a BA message after 492 receiving an LBU message from the MN. The MAP MUST insert in the BA 493 message a new hop-by-hop option called "Virtual Binding" (VB). The 494 VB must carry the MN's two IPv6 addresses sent to the MAP in the BU, 495 the binding lifetime and the "Address Management Key" (Kam). Note 496 that the Kam SHOULD be derived from hashing the shared secret 497 established between the MN and the MAP so that the MN does not need 498 to store a new Key. 500 Finally, the MAP MUST authenticate the VB option with the Kam and 501 MUST encrypt the Kam field with a shared key pre-computed between the 502 MAP and the VMAPs. 504 Upon receiving a BA message carrying a VB hop-by-hop option, the VMAP 505 starts by checking if its VBCE has an entry corresponding to the MN's 506 LCoA. If this is the case, the VMAP should update any existing value 507 (e.g., binding lifetime) with the new one carried in the VB option. 508 In case there is no entry, the VMAP MUST create one, which includes 509 all data sent in the VB. 511 The third step occurs when the MN switches to a new link. In such 512 scenario, the MN starts by sending a RtSol message, which MUST 513 contain its RCoA, its pLCoA and a proof of ownership of the two 514 addresses. 516 The proof is carried in a new option (i.e., "Address Check" (AC) 517 option defined in Section 9.1) and is presented as the result of the 518 following: 520 Proof = First[64, HMAC(Kam, (RCoA | pLCoA)] 522 The MN's addresses and the proof of ownership are carried in two 523 different options defined in Section 9.1 and Section 9.2 525 The VMAP MUST delete from its VBCE all information related to one 526 particular MN upon the expiration of the binding lifetime, unless 527 another BA is sent by the MAP carrying a new binding lifetime (i.e., 528 the MN has sent a new LBU message carrying the same LCoA to the MAP). 530 The next step in the OMM protocol consists on triggering a network 531 handover (NH). This is done by the MN's nAR upon receiving a RtSol 532 message, which contains the two options. In such scenario, the AR 533 SHOULD send in parallel a Route Path Update (RPU) message to the MN's 534 pLCoA (carried by the RtSol message) and a RtAdv message to the MN. 535 Note that the RPU message MUST be signed by the nAR. 537 When a VMAP receives an RPU message, it starts by checking its VBCE 538 for an entry which contains the couple (RCoA, pLCoA). If an entry is 539 found, the VMAP fisrct hecks whether the proof contained in the 540 message is valid. If so, it computes the MN's nLCoA IID and updates 541 its VBCE with the new MN's nLCoA. The same IID MUST be computed by 542 the MN and in the same following way: 544 nLCoA(IID) = First[64, HMAC(Kam, (RCoA | pLCoA | New_Subnet_Prefix)] 546 After updating its VBCE, the VMAP starts tunnelling data packets sent 547 by the MAP to the MN's pLCoA to its new location (i.e., nLCoA). The 548 VMAP MUST delete the MN's correponding entry from its VBCE at the 549 expiration of the routing binding lifetime (RBL) sent by the MN's nAR 550 in the RPU message. Note that the RBL value may be predefined. 552 After the MN gets a new LCoA, it MUST send an LBU message to the MAP. 553 The LBU message updates the MAP's BCE, re-route the data traffic by 554 using a more optimized route between the MAP and the MN and update 555 the VMAP (i.e., via the BA message) on the new path between the MN 556 and the MAP. It should be noted that many VMAPs may be updated by 557 one specific BA message. However, the decision to turn on/off more 558 than one VMAP on a particular path should be taken based on the 559 network topology around that path. 561 8. Mobility for Dormant Mode Mobile Nodes 563 In addition to the micro-mobility optimization described for active 564 MNs, this proposal introduces a new technique to page MNs while being 565 in dormant mode and moving across different Paging Zones (PZ). Our 566 approach applies the hash-based paging procedure using bloom filters 567 [HBP] to the OMM protocol. Note that such technique can be used to 568 page several MNs located in the same PZ concurrently, thus 569 significantly reducing the paging bandwidth consumption and the call 570 setup delays. 572 As mentioned earlier, our solutions consists on adding Paging Agent 573 (PA) functionalities to the VMAPs. In addition, the suggested 574 solution introduces a new Paging Zone Identifier (PZI), which allows 575 the MN to detect when entering to a new PZ. The PZI MUST be carried 576 in the RtAdv message. 578 When a MN in a dormant mode detects that the PZI has changed, it MUST 579 send a RtSol message to the AR. The RtSol message MUST carry its HoA 580 and the PZI. The latter is used to notify the AR, i.e., VMAP, that 581 the MN is in a dormant mode. Upon receiving the RtSol message, the 582 AR sends an LU message to the MAP to notify it about the new location 583 of the MN. The LU message MUST contain the MN's RCoA and MUST be 584 authenticated by the VMAP. When the MAP receives an LU message, it 585 creates/updates the MN's corresponding BCE with the new source 586 address, i.e., VMAP, sent in the LU message. After that the MAP MAY 587 send back an LA message to the VMAP 589 When an incoming call arrives to the MN's RCoA address, the MAP 590 starts by checking the corresponding BCE and tunnels the packet to 591 the corresponding VMAP. The receipt of a packet carrying a VMAP 592 address as destination address serves to notify the VMAP that the 593 inner destination address, i.e., RCoA, carried by the packet needs to 594 be paged. For this purpose, the VMAP will periodically, e.g., every 595 1 second, generate an 128-bit parameter using all RCoAs that need to 596 be paged, i.e., to empty its queue. The computed parameter and all 597 hash functions used to generate it are carried by the paging message 598 sent by the VMAP to all nodes in its PZ. Upon receiving paging 599 message, a MN SHOULD process it in the following way: 601 o If the MN is in active mode, then it SHOULD discard the message. 603 o If the MN is in dormant mode, then it can detect if it is being 604 paged by checking the bits positions {H1(RCoA), H2(RCoA), ..., 605 Hk(RCoA)} in the 128-bit parameter sent in the Pmes. Note that 606 {H1(), H2(), ...} are the hash functions used by the PA to compute 607 the parameter from the set of RCoAs which are waiting in the queue 608 to be paged. If any of the bit position is 0, then the 609 corresponding RCoA is not paged. Otherwise, the MN's RCoA is 610 paged and MUST proceed according in the same way described above 611 for an active MN. 613 9. OMM New Bits, Options and Messages Structure 615 As it has been shown above, the OMM Protocol defines 4 new bits, 6 616 new options and introduces 1 new message. 618 OMM defines new bit and options to be carried by the RtSol message. 619 The new bit and options are the following: 621 9.1 The Address Check Information Option (ACIO) 623 This option is used to carry the address check proof created by the 624 mobile node. This option is used to verify whether the mobile node 625 is really the owner of the addresses carried in the OMMIO option The 626 format of the option is the following: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Option Type | Option Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Address Proof | 634 | | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Option Type 638 640 Option Length 641 Length of the option. 643 Option Data 644 This contains the proof of ownership of the pLCoA and the RCoA 646 9.2 The Optimized Micro-Mobility Information Option (OMMIO) 648 The Optimized Micro-Mobility Information Option (OMMIO) is a new 649 option carried by the RtSol message sent by the MN upon receiving an 650 RtAdv message from the AP. When used, the OMMIO MUST carry the MN's 651 pLCoA and the RCoA. 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Option Type | Option Length | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | | 659 . pLCoA . 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 . RCoA . 664 | | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Option Type 668 670 Option Length 671 Length of the option. 673 Option Data 674 This contains the pLCoA and the RCOA of the mobile node 676 9.3 Paging Zone Identifier Option (PZIO) 678 The PZI option will be specified in a future version of this 679 document. 681 9.4 The VMAP (V) Bit 683 The VMAP bit is a new bit used in the OMM proposal to request VMAP 684 node(s) located between the MAP and the MN's current location to 685 store the MN's addresses (i.e., RCoA and LCoA) and the binding 686 lifetime in their VBCE(s). The VMAP bit MUST be set by the MAP in 687 the BA message each time the MAP receives a valid LBU message from 688 the MN. Note that the MN MUST ignore such bit. 690 9.5 Modified Router Solicitation message format 692 The modified Router Solication sent from a MN supporting this 693 specification would look like this 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | Code | Checksum | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Reserved | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | | 703 . ACIO . 704 | | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | | 707 . OMMIO . 708 | | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 IP Fields: 713 Source Address 714 The Source Address MUST be the MN's nLCoA. 716 Destination Address 717 Typically the all-routers multicast address. 719 Hop Limit 255 721 ICMP Fields: 723 Type 133 725 Code 0 727 Checksum The ICMP checksum. See [ICMPv6]. 729 Reserved This field is unused. It MUST be initialized 730 to zero by the sender and MUST be ignored by 731 the receiver. 733 9.6 Modified Binding Acknowledgement message format 735 When the binding acknowledgement message sent by the MAP it contains 736 the VMAP (v) bit as described. The modified BA looks like this. 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Status |K|V| Reserved | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Sequence # | Lifetime | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | | 744 . . 745 . Mobility options . 746 . . 747 | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 9.7 The Routing Path Update (RPU) Message 752 The Routing Path Update message sent from a nAR supporting this 753 specification would look like this 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Code | Checksum | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Reserved | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 . ACIO . 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | 767 . OMMIO . 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 IP Fields: 773 Source Address 774 The Source Address MUST be one of nARs addresses. 776 Destination Address 777 The pLCoA of the MN. 779 ICMP Fields: 781 Type 783 Code 0 785 Checksum The ICMP checksum. See [ICMPv6]. 787 Reserved This field is unused. It MUST be initialized to zero 788 by the sender and MUST be ignored by the receiver. 790 ACIO The Address check information option as specified above 792 OMMIO The OMM information option as specified above 794 9.8 The Location Update (LU) Message 796 The location update message will be specified in a future version of 797 this document. 799 9.9 The Location Acknowledgement (LA) Message 801 The location acknowledgment message will be specified in a future 802 version of this document. 804 10. Security Considerations 806 The OMM protocol assumes that all signaling messages exchanged 807 between routers (e.g., VMAPs) located within a MAP domain are 808 authenticated. 810 The OMM protocol does not introduce nor amplify any new or existing 811 attacks or threats. However, it should be noted that triggering a 812 network handover without providing a proof of ownership of the 813 previous LCoA mentioned in the RtSol message sent by the MN to the 814 nAR may allow to re-direct/steal data packets sent to another node 815 attached to the MN's previous AR. 817 11. Normative References 819 [EAR] J. Choi, D., Shin, "Fast Router Discovery with RA 820 Caching", draft-jinchoi-dna-frd-00, July 2004. 822 [ICMPv6] A. Conta, S. Deering, M. Gupta, "Internet Control 823 Message Protocol (ICMPv6) for the Internet Protocol 824 Version 6 (IPv6) Specification", 825 draft-ietf-ipngwg-icmp-v3-06, November 2004. 827 [HMIPv6] H. Soliman, K. elMalki, C. Castelluccia, L. Bellier, 828 "Hierarchical Mobile IPv6 mobility management 829 (HMIPv6)", draft-ietf-mipshop-hmipv6-04, December 2004. 831 [MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in 832 IPv6", RFC 3775, June 2004. 834 [NDIS] T. Narten, E. Nordmark, W. Simpson, H. Soliman, 835 "Neighbor Discovery for IP Version 6 (IPv6)", 836 draft-ietf-ipv6-2461bis-01, October 2004. 838 [SEND] J. Arkko, J. Kempf, B. Sommerfield, B. Zill, 839 P. Nikander, Secure Neighbor Discovery (SEND), 840 draft-ietf-send-ndopt-06, July, 2004. 842 [TERM] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 12. Informative References 847 [CIP] A. Valko, "Cellular IP: A New Approach to Internet Host 848 Mobility", ACM Computer Communication Review, January 849 1999. 851 [HAWAII] R. Ramjee, K. Varadhan, L. Salgarelli, S. Thuel, S.Y. 852 Wang, T. La Porta, "HAWAII: A Domain-based Approach for 853 Supporting Mobility in Wide-Area Wireless Networks," 854 IEEE/ACM Transactions on Networking, , Vol 10, No. 3, 855 June, 2002. 857 [HBP] P. Mutaf and C. Castelluccia, "Hash-Based Paging and 858 Location Update Using Bloom Filters", ACM/Kluwer 859 Journal on Mobile Networks and Applications, (MONET), 860 Vol. 10, No. 2, December 2004. 862 [TOMOP] L. Peters, I. Moerman, B. Dhoedt, P. Demeester, 863 "Influence of the Topology on the Performance of 864 Micromobility Protocols", Proceedings of WiOpt'03, 865 March 2003, Sophia Antipolis, France. 867 [MIPS] D. Saha, A. Mukherjee, I. Misra, M. Chakraborty, N. 868 Subhash, "Mobility Support in IP: A Survey of Related 869 Protocols", IEEE Network, Vol. 18 No. 6, November 2004. 871 [Paging] J. Kempf, "Dormant Mode Host Alerting ("IP Paging") 872 Problem Statement", RFC 3132, June 2001. 874 13. References 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", RFC 2119, March 1997. 879 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 880 (IPv6) Specification", RFC 2460, December 1998. 882 Authors' Addresses 884 Wassim Haddad 885 Ericsson Research 886 8400 Decarie Blvd. 887 Town of Mount Royal, QC 888 Canada 890 Phone: +1 514 345 7900 #2334 891 Email: Wassim.Haddad@ericsson.com 893 Suresh Krishnan 894 Ericsson Research 895 8400 Decarie Blvd. 896 Town of Mount Royal, QC 897 Canada 899 Email: Suresh.Krishnan@ericsson.com 901 Hesham Soliman 902 Flarion 904 Email: H.Soliman@flarion.com 906 Greg Daley 907 Monash University CTIE 908 Centre for Telecommunications and Information Engineering 909 Department of Electrical and Computer Systems Engineering 910 Monash University, Clayton, Victoria 3800 911 Australia 913 Phone: +61 3 9905 4655 914 Email: Greg.Daley@eng.monash.edu.au 916 Hannes Tschofenig 917 Siemens AG 918 Otto-Hahn-Ring 6 919 81739 Munich 920 Germany 922 Email: Hannes.Tschofenig@siemens.com 924 Intellectual Property Statement 926 The IETF takes no position regarding the validity or scope of any 927 Intellectual Property Rights or other rights that might be claimed to 928 pertain to the implementation or use of the technology described in 929 this document or the extent to which any license under such rights 930 might or might not be available; nor does it represent that it has 931 made any independent effort to identify any such rights. Information 932 on the procedures with respect to rights in RFC documents can be 933 found in BCP 78 and BCP 79. 935 Copies of IPR disclosures made to the IETF Secretariat and any 936 assurances of licenses to be made available, or the result of an 937 attempt made to obtain a general license or permission for the use of 938 such proprietary rights by implementers or users of this 939 specification can be obtained from the IETF on-line IPR repository at 940 http://www.ietf.org/ipr. 942 The IETF invites any interested party to bring to its attention any 943 copyrights, patents or patent applications, or other proprietary 944 rights that may cover technology that may be required to implement 945 this standard. Please address the information to the IETF at 946 ietf-ipr@ietf.org. 948 Disclaimer of Validity 950 This document and the information contained herein are provided on an 951 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 952 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 953 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 954 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 955 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 958 Copyright Statement 960 Copyright (C) The Internet Society (2005). This document is subject 961 to the rights, licenses and restrictions contained in BCP 78, and 962 except as set forth therein, the authors retain all their rights. 964 Acknowledgment 966 Funding for the RFC Editor function is currently provided by the 967 Internet Society.