idnits 2.17.1 draft-sjkoh-mip4-regional-handover-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 194 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2003) is 7469 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) ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-07 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. '5') Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Seok Joo Koh, ETRI 3 Internet Engineering Task Force Hee Young Jung, ETRI 4 Expires May 2004 November 2003 6 Fast Handover for Regional MIPv4 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026 [1]. 15 Internet-Drafts are valid for a maximum of six months and may be 16 updated, replaced, or obsoleted by other documents at any time. It is 17 inappropriate to use Internet-Drafts as reference material or to cite 18 them other than as a "work in progress". 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 This document addresses how to support fast handover in regional MIPv4 29 networks (Regional Hanover). The proposed regional handover scheme is 30 designed based on the existing MIPv4 Post-Registration scheme in a 31 more effective way that the regional MIPv4 features are exploited. In 32 the proposed regional handover scheme, the GFA acts as an anchor FA 33 and thus the bi-directional handover tunnels are established between 34 GFA and nFA, not between oFA and nFA. 36 Table of Contents 38 1. Introduction..................................................3 39 2. Terminology...................................................4 40 3. Overview of F-HMIPv4..........................................5 41 3.1 Reference Architecture....................................5 42 3.2 Motivations for F-HMIPv4..................................6 43 3.3 Design Principles.........................................7 44 4. F-HMIPv4 Operations...........................................9 45 4.1 Source Triggered Handover.................................9 46 4.2 Target Triggered Handover................................12 47 5. Message Format for F-HMIPv4..................................14 48 5.1 Handover Request (HRqst).................................14 49 5.2 Handover Reply (HRply)...................................15 50 6. Further Considerations.......................................16 51 6.1 Mobile Triggered Handover in F-HMIPv4....................16 52 6.2 When will GFA Start Data Forwarding to nFA...............16 53 6.3 How to Use F-HMIPv4 over HMIPv4 Networks.................16 54 7. Security Considerations......................................17 55 8. Acknowledgement..............................................17 56 9. References...................................................18 57 Author's Addresses..............................................18 59 1. Introduction 61 The MIPv4 [3] could be benefited from its two extensions: Regional 62 Registration for MIPv4 [4] and Low Latency Handover for MIPv4 [5]. 63 Those two extensional schemes have so far been designed in their own 64 ways so as to enhance the MIPv4 in the signaling and handover aspects. 65 It is clear that a combination of those two schemes gives the 66 harmonized benefit in terms of signaling overhead and latency (by 67 Regional MIPv4) as well as fast handover (by Low Latency handover). 69 This document addresses how to support fast handover in regional MIPv4 70 networks. The existing Low Latency handover scheme [5] provides the 71 two approaches for fast handover: Pre-Registration and Post- 72 Registration. 74 In the regional MIPv4 networks, the Pre-Registration handover scheme 75 seems to be effectively performed compared to the Post-Registration 76 scheme. However, in certain environments, e.g., in cases that the L2 77 handover is completed too earlier or the MN moves too faster, the 78 Post-Registration scheme MAY be preferred. This document focuses on 79 how to use the Post-Registration handover scheme over regional MIPv4 80 networks. 82 When applying the MIPv4 Post-Registration to Regional MIPv4 networks, 83 a bi-directional tunnel will be established between two FAs (oFA and 84 nFA). This simple combination may possibly induce additional 85 processing overhead for re-tunneling at oAR, since in regional MIPv4 86 networks all the data traffic is routed via GFA between MN and HA/CN. 87 This also incurs inefficient usage of network bandwidth. 89 This document describes 'Regional Handover' (i.e., Fast Handover for 90 Regional MIPv4). The proposed regional handover scheme is designed 91 based on the existing MIPv4 Post-Registration in a more effective way 92 such that the HMIPv4 features could be exploited. In the regional 93 handover scheme, the GFA will always act as an anchor FA (aFA), in 94 which all the handover tunnels will be established by GFA. 96 In the regional handover, it is assumed that the GFA has already 97 information about the Link Layer Address (LLA) and IP address (CoA) of 98 the FAs located in its HMIPv4 domain. This document describes the 99 regional handover operations for the Source Triggered and Target 100 Triggered handover cases. The proposed regional handover scheme uses 101 the two types of messages, Handover Request (HRqst) and Handover Reply 102 (HRply) described [5], without defining any new messages. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [2]. 110 This document uses all the terminology described in the MIPv4 [3], 111 regional tunneling for MIPv4 [4], and low latency handover for MIPv4 112 [5] documents. 114 In addition, this document also uses the following abbreviations 115 alternately: 117 HMIPv4: 119 'Hierarchical Mobile IPv4', which refers to 'Regional Registration 120 or Tunneling for MIPv4' [4]. 122 FMIPv4: 124 'Fast Handover for Mobile IPv4', which refers to 'Low Latency 125 Handover for MIPv4' [5]. 127 F-HMIPv4: 129 'Fast Handover for Hierarchical MIPv4', which is proposed in this 130 document. 132 3. Overview of F-HMIPv4 134 3.1 Reference Architecture 136 This document addresses how to support fast handover in hierarchical 137 MIPv4 networks (F-HMIPv4). For this purpose, we consider a 138 hierarchically configured MIPv4 network, as shown in Figure 1. In the 139 figure it is assumed that the MNs and FAs (including GFA) in the 140 network are aware of HMIPv4 functionality specified in [4]. 142 +-------+ 143 | HA | 144 +-------+ 145 | +----+ 146 | | CN | 147 | +----+ 148 +-----+ | 149 | +---+ 150 | | 151 +-------+ 152 | GFA | 153 +-------+ 154 | | 155 | +--------+ 156 | | 157 +-----+ +-----+ 158 | oFA | | nFA | 159 +-----+ +-----+ 161 +----+ 162 | MN | --------------> 163 +----+ movement 165 Figure 1: A Reference Network for F-HMIPv4 167 When an MN enters a new HMIPv4 domain, it will perform Home 168 Registration with HA via GFA by sending Registration Request message. 169 After that, whenever the MN moves into another FA region, it will 170 follow the HMIPv4 Regional Registration procedures [4]. 172 If the MN has an active session during the move, it is required to 173 support fast handover for seamless mobility services, in particular 174 for the real-time applications, as described in FMIPv4 [5]. 176 3.2 Motivations for F-HMIPv4 178 It is clear that a combination of FMIPv4 and HMIPv4 gives the 179 harmonized benefit in terms of signaling overhead and latency (by 180 HMIPv4) as well as fast handover (by FMIPv4). 182 FMIPv4 provides the two schemes for fast handover: Pre-Registration 183 and Post-Registration [5]. 185 The FMIPv4 Pre-Registration seems to be effectively applied in the 186 HMIPv4 networks, rather than the Post-Registration scheme, since the 187 MN will perform Pre-Registrations with the GFA not HA in the long 188 distance. However, the Pre-Registration scheme may not be effective in 189 certain environment that the L2 handover is completed too earlier or 190 the MN moves too faster. This document focuses on how to apply or 191 enhance the Post-Registration over HMIPv4 networks. 193 The existing FMIPv4 Post-Registration supports the handover using a 194 bi-directional tunnel, without performing the HMIP regional 195 registration by MN, and hence no registration messages are required 196 for handover support. Instead, the Post-Registration utilizes the Bi- 197 directional Edge Tunnel (BET) between oFA and nFA for fast handover. 199 In case of using the FMIPv4 Post-Registration in HMIPv4 networks, a 200 BET will be established between two FAs (oFA and nFA) by the FMIPv4 201 procedures. This simple combination of FMIPv4 and HMIPv4 may possibly 202 induce additional processing overhead for re-tunneling at oAR, since 203 in HMIPv4, all the data traffic is routed via GFA between MN and HA/CN. 204 This also incurs inefficient usage of network bandwidth. 206 Figure 2 shows the data flow by the simple integration of FMIPv4 with 207 HMIPv4. According to the HMIPv4 operations, the data packets sent by 208 CN/HA will arrive at GFA and then be tunneled to MN over oFA. 210 CN/HA oFA GFA nFA 211 | | | | 212 | MIPv4 | | 213 |---------------------->| | 214 | | HMIPv4 | | 215 | |<----------| | 216 | | FMIPv4 | 217 | |---------------------->| 218 | | | | 220 Figure 2: Data flows by FMIPv6 (Post) in HMIPv6 networks 222 When the handover is initiated by an L2 trigger, a BET tunnel will be 223 established between oFA and nFA according to the FMIPv4 Post- 224 Registration procedures. To forward the data packets to the nFA by 225 using the tunnel, the oFA must first intercept those data packets 226 flowing from the GFA, and then perform the re-tunneling process. This 227 may be done by adding a new outer IP header of to the data packets sent by GFA according to the 229 HMIPv4 operations. 231 In the viewpoint of the HMIPv4 operations, the above straightforward 232 approach has the following disadvantages: 234 (1) In HMIPv4, the actual data path of the BET between oFA and nFA may 235 come along the GFA (i.e., oFA-GFA-nFA). Accordingly, the data 236 packets will flow twice along the path between oFA and GFA. This 237 induces inefficiency of network bandwidth usage, especially when 238 those FAs are connected to the network through bandwidth-limited 239 links. 241 (2) In this scheme, the handover event of MN from oFA to nFA will not 242 be informed to GFA, despite that essentially the HMIPv4 regional 243 tunnel to nFA must be established by MAP. Accordingly, the 244 benefits of handover anticipation may be depreciated in this 245 scheme. 247 (3) From such detouring feature as described above, the overall 248 handover latency and tunneling overhead may increase during the 249 handover period. Moreover, it is likely to be difficult to exploit 250 the advantages of FMIPv4 and HMIPv4 as well. 252 3.3 Design Principles 254 3.3.1 Data Flow Optimization for F-HMIPv4 256 From the observations described above, it is clear that the fast 257 handover for HMIPv4 needs to be designed by considering the data 258 transport features of the HMIPv4 (i.e., in HMIPv4, all data packets 259 are intercepted by GFA and routed to MN. 261 This document describes Fast Handover for HMIPv4 (F-HMIPv4), in which 262 the GFA establishes the Bi-directional Tunnel (BT) with nFA for fast 263 handover instead of oFA. Note that such a tunnel is BT rather than BET, 264 since it is established between GFA and FA. Actually such a BT will 265 function as the regional tunnel described in [4]. 267 For this purpose, the FMIPv4 Post-Registration is re-designed in this 268 document. 270 Figure 3 illustrates the data flows by the F-HMIPv4. 272 CN/HA oFA GFA nFA 273 | | | | 274 | MIPv4 | | 275 |---------------------->| | 276 | | | | 277 | | | F-HMIPv4 | 278 | | |---------->| 279 | | | | 281 Figure 3: Data flows by F-HMIPv4 handover 283 Before handover, according to the HMIPv4 operations, the data packets 284 destined to MN are tunneled by GFA. When the F-HMIPv4 handover is 285 triggered (e.g., by L2 triggers), the GFA will establish a bi- 286 directional tunnel with the nFA, and then begin to forward the data 287 packets to the nFA over the tunnel. 289 When receiving the tunneled data packets from the GFA, the nFA will 290 de-capsulate and cache the data packets. It then will deliver the 291 cached data packets to the MN, as done in FMIPv4, when the MN moves 292 into the nFA region. 294 3.3.2 Assumptions 296 The F-HMIPv4 is newly designed based on the existing FMIPv4 Post- 297 Registration in a more effective manner by exploiting the HMIPv4 298 features. In F-HMIPv4, the GFA always acts as an anchor FA (aFA) of 299 FMIPv4, in which all the BET tunnels for fast handover will be 300 established by GFA. 302 In F-HMIPv4, it is assumed that the GFA has already information about 303 the Link Layer Address (LLA) and IP address (CoA) of the FAs located 304 in its HMIPv4 domain. This ensures that in response to the handover 305 (or BET establishment) request from an FA, the GFA could identify the 306 CoA of the FA concerned with the handover. 308 Basically the F-HMIPv4 operates over the HMIPv4 networks. Accordingly, 309 it is assumed that the FAs and MNs in the domain are aware of the 310 HMIPv4 functionality. For handover, the F-HMIPv4 procedures described 311 in this document apply to the concerned FAs and MN. 313 3.3.3 F-HMIPv4 Messages 315 The F-HMIPv4 uses the two types of messages, Handover Request (HRqst) 316 and Handover Reply (HRply), as those defined in the FMIPv4 [5] without 317 defining any new messages. 319 The messages are used with different operation procedures for BT 320 establishment between GFA and nFA, which will be described in the next 321 section. The two messages are also used differently by the type of L2 322 triggers (ST or TT) and by the entity generating the message (FA or 323 GFA). 325 In this context, the following notations for two message types are 326 used in this document: 328 HRqst(s/t/r, FA/GFA) and HRply(s/t/r, FA/GFA), 330 where s, t, and r represent ST, TT, tunnel removal or renewal, 331 respectively, and also the FA or GFA means that the corresponding 332 message is transmitted by FA or GFA, respectively. 334 To indicate who generates the message, a new flag F is added to the 335 HRqst and HRply messages defined in FMIPv4 [5]. The detailed message 336 format will be discussed in Section 5. 338 4. F-HMIPv4 Operations 340 In this section, we describe the F-HMIPv4 operations for the Source 341 Triggered and Target Triggered handover cases. The Mobile Triggered 342 handover is discussed in Section 6. 344 It is assumed that the MNs and FAs located in the domain are aware of 345 the HMIPv4 and also F-HMIPv4 described in this document. 347 It is assumed in F-HMIPv4 that that the GFA already has the 348 information about the LLA and CoA (IP address) for each FA located in 349 the HMIPv6 domain. When an MN enters a new HMIPv4 domain and moves 350 around in the domain, it will activate the home and regional 351 registration procedures defined in HMIPv4 [4]. 353 If the MN has an active session and moves to the other FA in the 354 domain, then the F-HMIPv4 applies for supporting fast handover. 356 4.1 Source Triggered Handover 358 In this section, we describe the F-HMIPv4 operations for the Source 359 Triggered handover. Figure 4 shows overall operations for Source 360 Triggered F-HMIPv4 handover. 362 +------+ 363 +--->| GFA |<---+ 364 | +->+------+ | 365 2) HRqst(s,FA) | | | 3) HRqst(s,GFA) 366 5) HRply(s,GFA) | |6) Redirect | 4) HRply(s,FA) 367 | | Request | 368 v | v 369 1) L2-ST ~~~> +------+ +------+ 370 | oFA | | nFA | 371 6) L2-LD ~~~> +------+ +------+ <~~~ 7) L2-LU 372 ^ ^ 373 old L2 | | new L2 374 +-----+ +-------+ 375 | | 376 | | 377 V V 378 +-------+ movement 379 7) L2-LU ~~~> | MN | ---------> 380 +-------+ 382 Figure 4: Source Triggered Handoff 384 The general idea behind the Source Triggered handover procedure is 385 that the oFA provides GFA with the same information it would have 386 obtained via an L2-ST, and then the GFA establishes a BT with nFA in 387 order to move the BET to nFA. When the L2 handover is complete (by L2- 388 LD), oFA sends an HRqst(r,FA) to GFA so as to terminate the previous 389 BET. 391 The following describes the process of the Source Triggered F-HMIPv4 392 handover. The numbered items refer to steps in Figure 4. 394 1) The oFA receives an L2-ST that contains the MN's L2 address (LLA) 395 and an IP address or LLA (that can be mapped to IP address) for 396 nFA. 398 2) The oFA sends HRqst(s,FA) to GFA for handover request, which 399 contains the MN's home IP address (HoA), the GFA IP address, an 400 LLA for the nFA, and an LLA containing the MN's L2 address. 402 3) Upon receipt of the HRqst(s,FA), the GFA gets the IP address 403 (CoA) of nFA from its pre-configured mapping table (which must 404 always maintain the mapping between LLA and CoA for all the nFAs). 405 The GFA then tries to establish a BT with nFA by sending 406 HRqst(s,GFA) to nFA. The HRqst(s,GFA) contains the MN's home IP 407 address (HoA) and an LLA containing the MN's L2 address. 409 4) In response to HRqst(s,GFA), the nFA sends HRply(s,FA) to GFA for 410 BT establishment. The HRply(s,FA) contains a code indicating that 411 the tunnel is successfully established. The nFA is ready to 412 receive and buffer the data packet from GFA over the BT. 414 5) Upon receipt of HRply(s,FA), the GFA sends HRply(s,GFA) to oFA, 415 which contains a code indicating that a BT has been successfully 416 established. 418 6) Once the L2 handover is underway and the MN gets disconnected at 419 L2 (by L2-LD), the oFA will request the GFA to start the tunnel 420 with nFA by sending an indication message explicitly such as ICMP 421 Redirect Request (See 6.2 for further discussion). 423 7) Completion of L2 handover is signaled by an L2-LU trigger at nFA 424 and/or MN. Then the nFA delivers the buffered data packets to the 425 MN. From then the nFA provides the data delivery service to the 426 MN. The MN either defers or initiates HMIP registration when it 427 receives the L2-LU, which will be discussed in Section 6. 429 Based on the description above, Figures 5 shows the timing diagram for 430 Source Triggered (L2-ST) F-HMIPv4 handover. 432 MN oFA GFA nFA 433 | | | | 434 | L2-ST ~~~~~>| | | 435 | | HRqst(s,FA) | | 436 | |------------->| HRqst(s,GFA) | 437 | | |--------------->| 438 | | |<---------------| 439 | |<-------------| HRply(s,FA)| 440 | | HRply(s,GFA)| | 441 | | | | 442 | L2-LD ~~~~~>|Redirect Request | 443 | |------------->| | 444 | | | L2-LU ~~~~~>| 445 |<---------------------------------------------->| 446 | MN's traffic | | | 448 Figure 5: Source Triggered F-HMIPv6 Timing 450 4.2 Target Triggered Handover 452 This section describes the F-HMIPv4 operations for the Target 453 Triggered handover. Figure 6 shows overall operations for Target 454 Triggered F-HMIPv4 handover. 456 +------+ 457 +--->| GFA |<---+ 458 | +->+------+ | 459 3) HRqst(t,GFA) | | | 2) HRqst(t,FA) 460 4) HRply(t,FA) | | 6) Redirect | 5) HRply(t,GFA) 461 | | Request | 462 v | v 463 +------+ +------+ <~~~ 1) L2-TT 464 | oFA | | nFA | 465 6) L2-LD ~~~> +------+ +------+ <~~~ 7) L2-LU 466 ^ ^ 467 old L2 | | new L2 468 +-----+ +-------+ 469 | | 470 | | 471 V V 472 +-------+ movement 473 7) L2-LU ~~~> | MN | ---------> 474 +-------+ 476 Figure 6: Target Triggered Handoff 478 In the Target Triggered handover, the nFA provides GFA with the 479 information that would have obtained via an L2-TT. Then the GFA gets 480 the information on MN (such as its HoA and LLA) for BT establishment 481 from the oFA, as shown as Steps 2 to 5 of Figure 6. The remaining 482 procedures (Steps 6 and 7) are identical to those for Source Triggered 483 handover. 485 The following describes the process of Target Triggered F-HMIPv4 486 handover for Steps 1 through 5. 488 1) The nFA receives an L2-TT that contains the MN's L2 address (LLA) 489 and an IP address or LLA (that can be mapped to IP address) for 490 oFA. 492 2) The nFA sends HRqst(t,FA) to GFA for handover request, which 493 contains the MN' home IP address (HoA), the GFA IP address, an 494 LLA for the oFA, and an LLA containing the MN's L2 address. 496 3) Upon receipt of the HRqst(t,FA), the GFA checks the IP address 497 (CoA) of oFA from its pre-configured mapping table. The GFA then 498 send HRqst(t,GFA) to oFA so as to get the information about MN's 499 home IP address (HoA) and an LLA containing the MN's L2 address. 501 4) In response to HRqst(t,GFA), the oFA sends HRply(t,FA) to GFA, 502 which contains the information for BET establishment. 504 5) Upon receipt of HRply(t,FA), the GFA sends HRply(t,GFA) to nFA, 505 which contains a code indicating that the handover request has 506 been successfully handled. The nFA is now ready to receive and 507 buffer the data packet from GFA over the BT. 509 Based on the description above, Figures 7 shows the timing diagram for 510 Target Triggered (L2-TT) F-HMIPv4 handover. 512 MN oFA GFA nFA 513 | | | | 514 | | | L2-TT ~~~~~>| 515 | | HRqst(t,GFA) |<---------------| 516 | |<-------------| HRqst(t,FA) | 517 | |------------->| | 518 | | HRply(t,FA) |--------------->| 519 | | | HRply(t,GFA) | 520 | | | | 521 | | | | 522 | L2-LD ~~~~~>|Redirect Request | 523 | |------------->| | 524 | | | L2-LU ~~~~~>| 525 |<---------------------------------------------->| 526 | MN's traffic | | | 527 | | | | 529 Figure 7: Target Triggered F-HMIPv6 Timing 531 5. Message Format for F-HMIPv4 533 The F-HMIPv6 uses two types of messages: HRqst and HRply. They have 534 the same message format as FMIPv4 [5] without defining any new message 535 type. Instead, a new flag bit 'F' is added in the message so as to 536 indicate the entity (such as FA or GFA) generating the concerned 537 message. The messages will be differently handled, depending on the 538 flags indicating the L2 trigger type (s or t) and the entity 539 generating the message (FA or GFA). 541 5.1 Handover Request (HRqst) 543 Figure 8 shows the HRqst message format, in which a new flag 'F' is 544 added to that defined in FMIPv4 [5]. This is a Mobile IP message 545 carried on UDP (destination port 434) [3]. The UDP header is followed 546 by the fields below. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type |H|N|R|M|G|T|B|F| Reserved | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Lifetime | Reserved | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | MN Home Address (HoA) | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | GFA Address | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | | 560 + Identification + 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Extensions ... 564 +-+-+-+-+-+-+-+- 566 Figure 8: Handover Request Message 568 Type TBD (Handover Request) as in [5] 570 H,N,R,M,G,T,B As defined in [5]. 572 F Flag to indicate the entity generating this 573 message. If set to '0', it represents that this 574 message is sent by FA. If otherwise set to '1', 575 this is sent by GFA. 577 Lifetime As defined in [5]. 579 MN Home Address As defined in [5]. 581 GFA Address IP address of GFA 583 Identification As defined in [5]. 585 Extensions The message MUST include an LLA containing the 586 MN's L2 address and an L2 address that can be 587 mapped to an IP address for the oFA or nFA, 588 appropriately as described in the F-HMIPv4 589 operations of Section 4. This message MUST also 590 contain the FA-FA Authentication Extension for 591 security purpose. 593 5.2 Handover Reply (HRply) 595 Figure 9 shows the HRply message format, in which a new flag 'F' is 596 added to that defined in FMIPv4 [5]. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type |H|N|R|M|G|T|B|F| Reserved | Code | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Lifetime | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | MN Home Address (HoA) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | GFA Address | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | 610 + Identification + 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Extensions ... 614 +-+-+-+-+-+-+-+- 616 Figure 9: Handover Reply Message 618 Type TBD (Handoff Reply), as in [5] 620 Code A value indicating the result of the corresponding 621 Handover Request (HRqst) 623 The remaining fields (including the flag 'F') are applied in the same 624 way as defined in the HRqst message. 626 6. Further Considerations 628 6.1 Mobile Triggered Handover in F-HMIPv4 630 Basically the F-HMIPv4 operates in the network-initiated fashion by 631 using Source or Target Trigger. If a Mobile Trigger (MT) is supported, 632 it may be used for MN to request the oFA that the Source Triggered 633 handover is initiated. Such a triggering or requesting message may be 634 newly defined in the L2 or L3 level, which is for further 635 investigation. 637 Alternatively, the MT may be used for triggering the FMIPv4 Pre- 638 Registration process as defined in [5]. In this case, the FAs and MNs 639 in the HMIPv4 domain are required to be aware of both FMIPv4 and F- 640 HMIPv4. 642 6.2 When will GFA Start Data Forwarding to nFA 644 By the F-HMIPv4 operations described in Section 4, the GFA establishes 645 a BT with nFA. After that, the GFA will start tunneling packets using 646 the BT to nFA, when receiving the ICMP Redirect Request message from 647 oFA indicating that the MN has disconnected. Instead of ICMP Redirect 648 message, the HRqst(r,FA) MAY be used for such indication, which is for 649 further investigation. 651 As another option, the GFA MAY start tunneling packets using the BT to 652 nFA as soon as establishing the BT with nFA, that is, after receiving 653 the HRply(s,FA) from the nFA in the Source Triggered handover case, or 654 after sending the HRply(s,GFA) to nFA for the Target Triggered 655 handover case. 657 6.3 How to Use F-HMIPv4 over HMIPv4 Networks 659 The F-HMIPv4 operates over HMIPv4 networks. Accordingly, the MN may 660 perform the HMIPv4 Regional Registration when it enters a new FA 661 region, independently of the F-HMIPv4 operations described in this 662 document. 664 In HMIPv4 [4], the GFA maintains the 'Visitor Entry List' that 665 includes the following fields for each MN: 667 o Current CoA of the MN 668 o Remaining Lifetime of the Regional Registration 670 On the other hand, by F-HMIPv4, GFA will keep the following fields: 672 o nFA CoA of the MN 673 o Remaining Lifetime of the Lifetime of the BT 675 Depending on the design of F-HMIPv4 with HMIPv4, when the GFA obtains 676 a new CoA (nFA CoA) of MN, and starts the data forwarding to the BT, 677 we have the following two choices for maintenance of the 'Visitor 678 Entry List': 680 (1) GFA updates the corresponding fields of 'Visitor Entry List'. 681 That is, the information by Regional Registration is handled in 682 the same as that by the F-HMIPv4 handover. 684 (2) GFA adds the information on BT for handover and maintains it 685 additionally. That is, the information by Regional Registration 686 is handled differently from that by the F-HMIPv4 handover. 688 It is for further study which one is a better choice. 690 7. Security Considerations 692 The security issues of F-HMIPv6 are basically in line with those of 693 HMIPv6 [4] and FMIPv4 [5]. 695 8. Acknowledgement 697 The Authors would like to give special thanks to the following people 698 for their valuable comments and discussion for enhancing the F-HMIPv4. 700 Sung Han Kim (ETRI) 701 Jun Seob Lee (ETRI) 703 9. References 705 [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP, 706 RFC 2026, October 1996. 708 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 709 Levels", BCP, RFC 2119, March 1997. 711 [3] C. Perkins, et al., "Mobility Support in IPv4", RFC 3344, August 712 2002. 714 [4] E. Gustafsson, et al., "Mobile IPv4 Regional Registration", draft- 715 ietf-mobileip-reg-tunnel-07, October 2002. 717 [5] K. Malki, et al., "Low Latency Handoffs in Mobile IPv4", draft- 718 ietf-mobileip-lowlatency-handoffs-v4-05, June 2003. 720 Author's Addresses 722 Seok Joo Koh 723 sjkoh@etri.re.kr 724 Protocol Engineering Center, ETRI 726 Hee Young Jung 727 hyjung@etri.re.kr 728 Protocol Engineering Center, ETRI