idnits 2.17.1 draft-ietf-mipshop-3gfh-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (April 13, 2008) is 5856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'AP-ID' on line 103 -- Looks like a reference, but probably isn't: 'AR-info' on line 103 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fmipv6-rfc4068bis-06 ** Obsolete normative reference: RFC 4282 (ref. '4') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '13') (Obsoleted by RFC 5380) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft KDDI Lab 4 Intended status: Informational G. Dommety 5 Expires: October 15, 2008 Cisco Systems, Inc. 6 April 13, 2008 8 Mobile IPv6 Fast Handovers for 3G CDMA Networks 9 draft-ietf-mipshop-3gfh-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Mobile IPv6 is designed to maintain its connectivity while moving 43 from one network to another. It is adopted in 3G CDMA networks as a 44 way to maintain connectivity when the mobile node moves between 45 access routers. However, this handover procedure requires not only 46 movement detection by the MN, but also the acquisition of a new 47 care-of address and Mobile IPv6 registration with the new care-of 48 address before the traffic can be sent or received in the target 49 network. During this period, packets destined for the mobile node 50 may be lost, which may not be acceptable for real-time application 51 such as Voice over IP (VoIP) or video telephony. This document 52 specifies fast handover methods in the 3G CDMA networks in order to 53 reduce latency and packet loss during handover. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Network reference model for Mobile IPv6 over 3G CDMA 61 networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Fast handover procedures . . . . . . . . . . . . . . . . . . . 9 63 5.1. Predictive fast handover . . . . . . . . . . . . . . . . . 9 64 5.2. Reactive fast handover . . . . . . . . . . . . . . . . . . 14 65 5.3. Considerations on the link indications . . . . . . . . . . 17 66 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18 67 6.1. Handover Assist Information Option . . . . . . . . . . . . 18 68 6.2. MN ID Option . . . . . . . . . . . . . . . . . . . . . . . 19 69 6.3. New flag extension to FBU message . . . . . . . . . . . . 19 70 6.4. New flag extension to PrRtAdv message . . . . . . . . . . 20 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 78 Intellectual Property and Copyright Statements . . . . . . . . . . 27 80 1. Requirements notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [1]. 86 2. Introduction 88 Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP 89 connectivity while the MN moves around in the IPv6 network. It is 90 adopted in 3G CDMA networks for handling host based mobility 91 management [11]. During handover, however, the mobile node (MN) 92 needs to switch the radio link, to obtain a new Care-of Address (CoA) 93 and to re-register with the home agent (HA), which may cause a 94 communication disruption. This is not desirable for real-time 95 applications such as VoIP and video telephony. To reduce this 96 disruption time or latency, a fast handover protocol for Mobile IPv6 97 [3] is proposed. RFC4260 [6] further describes how this Mobile IPv6 98 Fast Handover could be implemented on link layers conforming to the 99 IEEE802.11 suite of specifications. However, 3G CDMA and IEEE802.11 100 networks are substantially different in the radio access, the 101 representations of the network nodes or parameters, and the network 102 attachment procedures; for example, the beacon scanning or NAR 103 discovery based on [AP-ID, AR-info] tuples specified in RFC4260 can 104 not be directly applied to 3G CDMA networks. This document therefore 105 specifies how Mobile IPv6 fast handovers can be applied in the 3G 106 CDMA networks. In addition to the predictive and reactive fast 107 handovers defined in RFC4068, if the lower layer can provide 108 necessary information for handover, network-controlled fast handover 109 can also be applied and hence defined in this document. 111 3. Terminology 113 This document refers to [3] for Mobile IPv6 fast handover 114 terminology. Terms that first appear in this document are defined 115 below: 117 Access Network Identifier (ANID) 118 An identifier that is used by the PDSN to determine whether the 119 MN is being handed off from the access network that was not 120 previously using this PDSN. Anytime the MN crosses into a new 121 region, which is defined by the ANID, it must re-register with 122 that Access Network. The ANID is further composed of the System 123 ID (SID), Network ID (NID) and Packet Zone ID (PZID) and these 124 values are administered by the operator. The lengths of the 125 SID, NID and PZID are 2 octets, 2 octets and 1 octet, 126 respectively. Thus that of the ANID occupies 5 octets [10]. 128 Forward Pilot Channel: 129 A portion of the Forward Channel that carries the pilot. The 130 Forward Channel is a portion of the physical layer channels 131 transmitted from the 3G CDMA access network to the MN. Further, 132 several sets of pilots (e.g. the active set or neighbor set) are 133 defined to determine when and where to handover. 135 Home Link Prefix (HLP): 136 The prefix address assigned to the home link where the MN should 137 send the binding update message. This is also called as Home 138 Network Prefix (HNP) and one of the bootstrap parameters for the 139 MN. 141 International Mobile Subscriber Identity (IMSI): 142 The IMSI is a string of decimal digits, up to a maximum of 15 143 digits, that identifies a unique mobile terminal or mobile 144 subscriber internationally. The IMSI consists of three fields: 145 the Mobile Country Code (MCC), the Mobile Network Code (MNC), 146 and the Mobile Subscriber Identification Number (MSIN). An 147 example of the IMSI is "440701234567890", where "440" is the 148 MCC, "70" is the MNC and "1234567890" is the MSIN. The IMSI 149 conforms to the ITU-T E.212 numbering standard [5]. In this 150 specification, IMSI is an ASCII string that consists of not more 151 than 15 decimal digits (ASCII values between 30 and 39 152 hexadecimal), one character per IMSI digit. The above example 153 would therefore be encoded as "34 34 30 37 30 31 32 33 34 35 36 154 37 38 39 30" in hexadecimal notation. 156 Mobile Identity (MN ID) 157 An Identify used by the access network to provide the Mobile 158 Node Identification. The value (e.g. IMSI) is unique within 159 the operator's network. 161 Packet Data Serving Node (PDSN): 162 An entity that routes MN originated or MN terminated packet data 163 traffic. A PDSN establishes, maintains and terminates link- 164 layer sessions to MNs. A PDSN is the access router in the 165 visited access provider network. 167 Sector Address Identifier (SectorID): 168 A typical cell divides its coverage area into several sectors. 169 In 3G CDMA systems, each sector uses a different PN (Pseudo 170 Noise) code offset and associated with SectorID. The SectorID 171 is 128-bit long and can be represented in the IPv6 address 172 format [7]. 174 4. Network reference model for Mobile IPv6 over 3G CDMA networks 176 Figure 1 shows a simplified reference model of the Mobile IP enabled 177 3G CDMA networks. The home agent (HA) and AAA server (AAA) of the 178 mobile node (MN) reside in the home IP network and the MN roams 179 within or between the access provider network(s). Usually, the home 180 IP network is not populated by the MNs, which are instead connected 181 only to the access provider networks. Prior to the Mobile IPv6 182 registration, the MN establishes a 3G CDMA access technology specific 183 link-layer connection with the access router (AR). When the MN moves 184 from one AR to another, the link-layer connection is re-established 185 and a Mobile IPv6 handover is performed. Those ARs reside in either 186 the same or different access provider network(s). The figure shows 187 the situation, where the MN moves from the previous access router 188 (PAR) to the new access router (NAR) via the radio access network 189 (RAN). 191 Home IP Network 192 +........................+ 193 . +--------+ +--------+ . 194 . | HA |--| AAA | . 195 . +--------+ +--------+ . 196 +../......\..............+ 197 / \ 198 Access Provider Network(s) 199 +.............+ +.............+ 200 . +---------+ . . +---------+ . 201 . | PAR | . . | NAR | . 202 . +---------+ . . +---------+ . 203 . |: . . :| . 204 . |:L2link L2link:| . 205 . |: . . :| . 206 . +----+:---+ . . +---:+----+ . 207 . | RAN | . . | RAN | . 208 . +----+:---+ . . +---:+----+ . 209 . |: . . :| . 210 . +----+ . . +----+ . 211 . | MN | ---------> | MN | . 212 . +----+ . . +----+ . 213 +.............+ +.............+ 215 Figure 1: Reference Model for Mobile IP 217 In 3G CDMA networks, pilot channels transmitted by base stations 218 allow the MN to obtain a rapid and accurate C/I (carrier to 219 interference) estimate. This estimate is based on measuring the 220 strength of the Forward Pilot Channel or the pilot, which is 221 associated with a sector of a base station (BS). The MN searches for 222 the pilots and maintains those with sufficient signal strength in the 223 pilot sets. The MN sends measurement results, which include the 224 offsets of the PN code in use and the C/Is in the pilot sets, to 225 provide the radio access network (RAN) with the estimate of sectors 226 in its neighborhood. There are several triggers for the MN to send 227 those estimates, e.g. when the strength of a pilot in the pilot sets 228 exceeds that of the current pilot, the MN sends the estimates to the 229 access network. As long as the sector to which the MN is going to 230 move belongs to the same access network, the mobility within that 231 access network is handled by the access specific interfaces [9] and 232 the link-layer connection between the MN and AR can be maintained 233 without a reestablishment. The MN can continually search for pilots 234 without disrupting the data communication and a timely handover is 235 assisted by the network. If, however, the serving access network 236 finds that the sector associated with the highest pilot strength 237 belongs to a different AR, it attempts to close the connection with 238 the MN. The MN then attempts to get a new traffic channel assigned 239 in the new access network, which is followed by establishing a new 240 connection with the new AR. This could cause a noticeable 241 communication disruption and lead to a serious degradation of the 242 user experience. In order to minimize the service degradation, 243 during the handover between ARs, an IP-level fast handover approach 244 as defined in RFC4068 needs to be involved. If the air interface 245 information can be used as a trigger for the handover between access 246 routers, fast and smooth handover of Mobile IPv6 can be realized in 247 3G CDMA networks. The MN can continually search for pilots without 248 disrupting the data communication and a timely handover is assisted 249 by the network. If the air interface information can be used as a 250 trigger for the handover between access routers, fast and smooth 251 handover of Mobile IPv6 can be realized in 3G CDMA networks. 253 To assist the handover of the MN to the new AR, various types of 254 information can be considered: the pilot sets, which include the 255 candidates of the target sectors or BSs, the cell information where 256 the MN resides, the serving nodes in the radio access network and the 257 location of the MN if available. To identify the access network that 258 the MN moves to or from, the Access Network Identifiers (ANID) or the 259 subnet information can be used [8][9]. In this document, a 260 collection of such information is called "handover assist 261 information". In 3G CDMA networks, the link-layer address of the new 262 access point defined in [3] may not be available. If this is the 263 case, the MN ID option defined in this document SHOULD be used 264 instead. 266 5. Fast handover procedures 268 There are two modes defined in [3] according to the time of sending 269 the FBU (Fast Binding Update); one is called "predictive mode," where 270 the MN sends the FBU and receives the FBAck (Fast Binding Ack) on the 271 PAR (Previous Access Router)'s link and the other is called "reactive 272 mode," where the MN sends the FBU from the NAR (New Access Router)'s 273 link. In the predictive mode, the time and place the MN hands off 274 must be indicated sufficiently before the time it actually happens. 275 In cellular systems, since handovers are controlled by the network, 276 the predictive mode is well applied. However, if the network is not 277 configured to be able to identify the new AR, to which the MN is 278 moving next, in a timely manner, the reactive mode is better applied. 280 RFC4907 [19] Section 2 suggests architectural principles on the link 281 indication and the effectiveness of the optimization. The link 282 indication of this document relies on 3G CDMA networks and the 283 effectiveness of the optimization is attributed to RFC4068bis. The 284 above principles are thus considered by the related specifications 285 referenced in this document. 287 5.1. Predictive fast handover 289 Figure 2 shows the predictive mode of MIPv6 fast handover operation. 290 When the MN finds a sector or a BS whose pilot signal is sufficiently 291 strong, it initiates handover according to the following sequence: 293 (a) A router solicitation for proxy router advertisement is sent to 294 the PAR. Handover assist information for the target 3G CDMA 295 network is attached to this message. 297 (b) Based on the received handover assist information, the NAR is 298 determined and a proxy router advertisement (PrRtAdv) containing 299 the prefix of the NAR is sent back to the MN. The MN also 300 checks that the R flag is not set in the PrRtAdv message, which 301 indicates the network supports the predictive fast handover mode 302 (defined later). 304 (c) The MN creates an NCoA (new CoA) and sends the Fast Binding 305 Update (FBU) with the NCoA to the PAR, which in turn sends the 306 Handover Initiate (HI) to the NAR. 308 (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR, 309 which in turn sends the FBU acknowledgment (FBAck) to the MN. 311 (e) The PAR starts forwarding packets toward the NCoA and the NAR 312 captures and buffers them. 314 (f) The link-layer connection associated with the PAR is closed and 315 a new traffic channel is assigned in the new access network. 317 (g) The MN attaches to the new access network. The attachment 318 procedure is access technology specific and that for 3G CDMA 319 network including the PPP transactions is described later. 321 (h) The MN sends the Unsolicited Neighbor Advertisement (UNA). 323 (i) The NAR starts delivering packets to the MN. 325 (j) The MN sends the BU to the HA to update the BCE with the NCoA 326 and the HA sends back the BA to the MN. 328 MN PAR NAR HA AAA 329 | RtSolPr | | | | 330 (a) |------------->| | | | 331 | PrRtAdv | | | | 332 (b) |<-------------| | | | 333 | FBU | Hl | | | 334 (c) |------------->|-------------->| | | 335 | FBack | HAck | | | 336 (d) |<-------------|<--------------| | | 337 | |forward packets| | | 338 (e) | |==============>|(buffering) | | 339 | | | | | 340 (f) handover | | | | 341 | | | | | 342 +--------------------------------------------------------------+ 343 (g) | Attachment procedure | 344 +--------------------------------------------------------------+ 345 | UNA | | | 346 (h) |----------------------------->| | | 347 | deliver packets | | | 348 (i) |<=============================| | | 349 | | BU/BA | | | 350 (j) |<------------------------------------------->| | 351 | | | | | 353 Figure 2: MIPv6 Fast handover operation (predictive mode) 355 It is assumed that the NAR can be identified by the PAR leveraging 356 the handover assist information from the MN. To perform the 357 predictive mode, the MN MUST send the FBU before the connection with 358 the current access network is closed. If the MN fails to send the 359 FBU before handover, it SHOULD fall back to the reactive mode. Even 360 if the MN successfully sends the FBU, its reception by the PAR may be 361 delayed for various reasons such as congestion. If the NAR receives 362 the HI triggered by the delayed FBU after the reception of the UNA 363 ((c) comes after (h)), then the NAR SHOULD send the HAck with 364 handover not accepted and behave as the reactive mode. 366 In (a), RtSolPr is supposed to include the New Access Point and the 367 MN Link-Layer Address (LLA) options (Option Code=1 and 2, 368 respectively) according to [3]. The New AP-LLA option MAY be 369 replaced by the handover assist information option in 3G CDMA 370 networks. As for the MN-LLA option, if the LLA for the MN is not 371 available, 3G specific IDs such as IMSI[10] MAY be used. If this is 372 the case, the MN ID option defined in Section 6.2, which can support 373 other types of IDs and a length that is not necessarily multiples of 374 8 octets, SHOULD be used instead of the MN-LLA option. 376 In (b), PrRtAdv MUST include options for the IP address of the NAR, 377 which may be the link-local address, and the prefix for the MN. The 378 PAR SHOULD be able to identify the NAR from the handover assist 379 information provided by the MN. 381 Figure 3 shows the call flow for the initial attachment in the 3G 382 CDMA network [11]. After the traffic channel is assigned, the MN 383 first establishes a link-layer connection between itself and the 384 access router. As a link-layer protocol, PPP is considered in this 385 figure, and a PPP handshake is depicted as an example. After a link- 386 layer connection is established, the MN registers with the HA by 387 sending a Binding Update message. There are several parameters for 388 using Mobile IPv6 such as the home address (HoA), the care-of address 389 (CoA), the home agent address (HA) and the home link prefix (HLP). 390 In [11], obtaining these values is called bootstrapping, and the 391 bootstrapping information can be obtained during the link-layer 392 establishment phase and/or the mobility binding phase [12]. 394 MN PAR NAR HA AAA 395 / | (serving PDSN) (target PDSN) | | 396 | | LCP | | | | 397 | (1) |<----------------------->| | | 398 | | CHAP/PAP | Access-Request/Accept | 399 | (2) |<----------------------->|<-------------|------->| 400 |. | | +------+ | | | 401 |.(3)* | | | HA |<---------+ | 402 |. | | +------+ | | 403 |+........................................+ | | 404 |. | | . | | 405 |. | IPv6CP(IF-ID) | . | | 406 |.(4)* |<---------|------------->| . | | 407 (g)< . +---------+ | | | . | | 408 |.(5)*| LL-addr |<-+ | | . | | 409 |. +---------+ | | . | | 410 |. | | . | | 411 |. | RA(prefix) | . | | 412 |.(6)* |<---------|--------------| . | | 413 |. +-----+ | | | . | | 414 |.(7)*| CoA |<-----+ | | . | | 415 |. +-----+ | | . | | 416 |+........................................+ | | 417 | | DHCPv6(HA) | | | 418 | (8) |<---------------+------->| | | 419 | +-----+ | | | | | 420 | (9) | HA |<-----------+ | | | 421 | +-----+ | | | | 422 | | | | | | 423 \ | | | | | 425 Figure 3: Attachment procedure in 3G CDMA network 427 The procedure for the initial attachment is as follows: 429 (g) The link-layer connection establishment and the bootstrapping 430 phase 432 (g-1) The LCP (Link Control Protocol) configure-request/response 433 messages are exchanged. 435 (g-2) User authentication (e.g. CHAP or PAP) is conducted. 437 (g-3) The static bootstrapping information is conveyed from the AAA 438 and stored in the NAR (target PDSN). The HoA and HLP can be 439 dynamically assigned by the HA in the mobility binding phase. 440 This step can be skipped in the handover case. 442 (g-4) Unique interface IDs are negotiated in IPv6CP. 444 (g-5) The MN configures its link-local address based on the obtained 445 interface ID. 447 (g-6) A router advertisement containing the prefix is received by 448 the MN. 450 (g-7) The MN configures its CoA based on the obtained prefix. 452 (g-8) DHCPv6 is used to obtain the static bootstrap information 453 (e.g. the HA address). This step is performed in the initial 454 attachment and can be skipped once the MN obtains those 455 parameters. 457 (g-9) The MN installs the bootstrap information for further 458 procedures (e.g. the mobility binding). 460 As is shown in Figure 3, it takes a considerable amount of time to 461 establish a link-layer connection and almost all of the above 462 sequences run every time the MN attaches to a new access network. It 463 is therefore beneficial if packets in transit to the MN are saved not 464 only during the time period when the MN switches to the new radio 465 channel but also during the time period when the MN establishes the 466 link-layer connection. 468 There are several ways to configure a unique IP address for the MN. 469 If a globally unique prefix is assigned per link as introduced in 470 [11], the MN can use any interface ID except that of the other peer 471 (the AR to which the MN is attached) to create a unique IP address. 472 If this is the case, however, the PAR cannot provide the MN with a 473 correct prefix for the new network in the PrRtAdv since such a prefix 474 is selected by the NAR and provided in the router advertisement. The 475 MN therefore configures a temporary NCoA with the prefix provided by 476 the PAR and the correct NCoA MUST be assigned by the NAR. Therefore, 477 in 3G CDMA network, the PAR MUST send the HI with the S flag set when 478 it receives the FBU from the MN at step (c) in Figure 2. 480 The UNA is supposed to include the MN-LLA [3], but the point-to-point 481 link-layer connection may be able to uniquely identify the MN. The 482 most required information by the UNA is the NCoA to check if there is 483 a corresponding buffer. In (h) therefore the function of the UNA can 484 be realized in several ways: 486 o Since the establishment of the link-layer connection in (g) 487 indicates readiness of data communication on the MN side, the NAR 488 immediately checks if there is a buffer that has packets destined 489 for the NCoA, which was configured at steps (c) - (d), and starts 490 delivering if any. (substitution of UNA) 492 o The MN sends the UNA as defined in [3]. Instead of the MN-LLA in 493 the LLA option, the MN ID MAY be included in the MN ID option. 494 (standard implementation of UNA) 496 The primary benefit of the predictive fast handover mode is that the 497 packets destined for the MN can be buffered at the NAR, and packet 498 loss due to handover will be much lower than that of the normal MIPv6 499 operation. Regarding the bootstrapping, the following benefit can be 500 obtained, too: 502 o Since the NCoA can be configured via the fast handover procedures, 503 a router advertisement is not required. 505 Therefore, the procedures (g-4) to (g-7) can be skipped from the 506 standard MIPv6 operation in Figure 3. 508 5.2. Reactive fast handover 510 When the networks does not support the predictive fast handover mode, 511 the reactive fast handover is applied. In this document, a new flag 512 is defined in PrRtAdv to inform the MN about the capability of the 513 network (see Section 6.4). To minimize packet loss in this 514 situation, the PAR instead of the NAR can buffer packets for the MN 515 until the MN regains connectivity with the NAR. The NAR obtains the 516 information of the PAR from the MN on the NAR's link and receives 517 packets buffered at the PAR. In this case, the PAR does not need to 518 know the IP address of the NAR or the NCoA and just waits for the NAR 519 to contact the PAR. However, since the PAR needs to know when to 520 buffer packets for the MN, the PAR obtains the timing of buffering 521 from the MN via the FBU or the lower layer signaling, e.g. an 522 indication of the release of the connection with the MN. Details of 523 the procedure are as follows: 525 (a) A router solicitation for proxy router advertisement MAY be sent 526 to the PAR. 528 (b) The proxy router advertisement MAY be sent to the MN, but the 529 prefix of the NAR is (or is not) included. 531 (c) The MN sends the FBU or the access network indicates the close 532 of the connection with the MN by the lower layer signaling. If 533 the B flag is set in the FBU, the PAR SHOULD start buffering 534 packets destined for the PCoA. 536 (d) The link-layer connection associated with the PAR is closed and 537 a new traffic channel is assigned in the new access network. 539 (e) The MN attaches to the new access network. This part is the 540 same as described in Section 5.1 and illustrated in Figure 3. 542 (f) The MN sends the UNA to the NAR. 544 (g) The MN sends the Fast Binding Update (FBU) to the PAR via the 545 NAR. 547 (h) The NAR forwards the FBU from the MN to the PAR. 549 (i) The PAR sends the Handover Initiate (HI) to the NAR with the 550 Code set to 1. 552 (j) The NAR sends the Handover Acknowledge (HAck) back to the PAR. 554 (k) The PAR sends the FBAck to the NAR. 556 (l) If the PAR is buffering packets destined for the PCoA, it starts 557 forwarding them as well as newly arriving ones to the NAR. 559 (m) The NAR delivers the packets to the MN. 561 (n) The MN sends the BU to the HA to update the BCE with the NCoA 562 and the HA sends back the BA to the MN. 564 MN PAR NAR HA AAA 565 | RtSolPr | | | | 566 (a) |------------->| | | | 567 | PrRtAdv | | | | 568 (b) |<-------------| | | | 569 | FBU | | | | 570 (c) |- - - - - - ->|(buffering) | | | 571 | | | | | 572 (d) handover | | | | 573 | | | | | 574 +--------------------------------------------------------------+ 575 (e) | Attachment procedure | 576 +--------------------------------------------------------------+ 577 | UNA | | | 578 (f) |----------------------------->| | | 579 | FBU | | | 580 (g) |----------------------------->| | | 581 | | FBU | | | 582 (h) | |<--------------| | | 583 | | HI | | | 584 (i) | |-------------->| | | 585 | | HAck | | | 586 (j) | |<--------------| | | 587 | | FBack | | | 588 (k) | |-------------->| | | 589 | |forward packets| | | 590 (l) | |==============>| | | 591 | deliver packets | | | 592 (m) |<=============================| | | 593 | | BU/BA | | | 594 (n) |<------------------------------------------->| | 595 | | | | | 597 Figure 4: MIPv6 Fast handover operation (reactive mode) 599 To indicate the PAR to buffer packets destined for the PCoA, in step 600 (c), a new flag 'B' is defined in the FBU. When the PAR receives the 601 FBU with this flag set, it SHOULD buffer packets for the MN. The PAR 602 MAY also start buffering packets for the MN based on lower layer 603 signal during handover. Since the packets are buffered at the PAR in 604 this scenario, the UNA, which is received and processed by the NAR, 605 can not be used to trigger to forward the buffered packets at the 606 PAR. In Figure 4, the HAck from the NAR is used as the trigger for 607 the forwarding of any buffered packets. 609 The handover indication from the lower layer of 3G CDMA system is 610 reasonably reliable by the periodical reports from the MN; however, 611 there are several situations where the target link is not available 612 after the handover (step (d)) and the MN comes back to the PAR, or 613 the MN is not able to move to the target link for some reason after 614 the connection was closed. If this is the case, the attachment 615 procedure is performed on the previous link. The packets buffered at 616 the PAR SHOULD be delivered to the MN after the connection is re- 617 established. 619 5.3. Considerations on the link indications 621 This section discusses if the link indications assumed in this 622 document meet the principles defined in RFC4907[19] Section 2, which 623 suggests 11 architectural principles on the link indication and the 624 effectiveness of the optimization. This document relies on the 3G 625 CDMA network regarding the link indication, which is precisely 626 specified by 3GPP2. Therefore, principles (1) to (5), (7), (8) and 627 (11), that is, "Model Validation", "Clear Definition", "Robustness", 628 "Recovery from Invalid Indications", "Congestion Control", 629 "Interoperability", "Race Condition" and "Transport of Link 630 Indications" are considered by those specs. Principle (6) 631 "Effectiveness" mentions the effectiveness of the optimization. This 632 document bases its effectiveness on RFC4068bis. Therefore this 633 principle is dealt by that RFC. Principle (9) "Metric Consistency" 634 mentions inconsistencies between link and routing layer metrics. The 635 spec of this document does not change the routing metrics and multi- 636 homing is not considered. Finally, principle (10) "Layer 637 Compression", mentions overhead reduction scheme and 638 interoperability. This document does not deal with overhead 639 reduction and therefore this principle does not apply. 641 6. Message Format 643 6.1. Handover Assist Information Option 645 If the lower layer information of the new point of attachment is not 646 represented as the Link-Layer Address, the following option SHOULD be 647 used. The primary purpose of this option is to convey the handover 648 assist information described in Section 4. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Type | Length | Option-Code | HAI-Length | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | HAI-Value... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 658 Type TBD1 660 Length The size of this option in 8 octets including the 661 Type, Length, Option-Code and AS-Length fields. 663 Option-Code 664 1: Access Network Identifier (AN ID) 665 2: Sector ID 667 HAI-Length The size of the HAI-Value field in octets. 669 HAI-Value The value specified by the Option-Code. 671 If those which received this message do not support this option, they 672 SHOULD treat this option as opaque and MUST NOT drop it. 674 Option-Code Indicates the particular type of handover assist 675 information. Currently, two types of information are defined to 676 assist the discovery of the NAR (See Section 3). 678 Depending on the size of the HAI-Value field, appropriate padding 679 MUST be used to ensure that the entire option size is a multiple of 8 680 octets. The HAI-Length is used to disambiguate the size of the HAI- 681 Value. 683 The handover assist information MAY replace the New Access Point 684 Link-Layer Address in 3G CDMA networks. 686 6.2. MN ID Option 688 This option is used to transfer the Identifier of the MN, which is 689 not its link-layer address. 691 0 1 2 3 692 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 693 +---------------+---------------+---------------+---------------+ 694 | Type | Length | Option-Code | MN ID-Length | 695 +---------------------------------------------------------------+ 696 | MN ID ... 697 +----------------------------- 699 Type TBD2 701 Length The size of this option is in 8 octets including the 702 Type, Length and Option-Code. 704 Option-Code 705 1: NAI [4] 706 2: IMSI (See Section 3) 708 MN ID-Length The length of the MN ID in octets. 710 MN ID MN ID value 712 The MN ID MAY replace the MN Link-Layer Address in 3G CDMA networks. 714 6.3. New flag extension to FBU message 716 The MN MUST send the FBU to the PAR with the following new (B) flag 717 set in the previous network to indicate the PAR to buffer packets 718 destined for the PCoA. The rest of the Binding Update message format 719 remains the same as defined in [2] and with the additional (M), (R) 720 and (P) flags as specified in [13], [14] and [15], respectively. 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Sequence # | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |A|H|L|K|M|R|P|B| Reserved | Lifetime | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | | 728 . . 729 . Mobility options . 730 . . 731 | | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 B flag: If the 'B' flag is set, the PAR SHOULD start buffering 735 the packets destined for the MN as specified in 736 Section 5.2. 738 6.4. New flag extension to PrRtAdv message 740 A new flag 'R' is defined in the PrRtAdv to inform the MN about the 741 fast handover mode that the network supports. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Type | Code | Checksum | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Subtype |R| Reserved | Identifier | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Options ... 751 +-+-+-+-+-+-+-+-+-+-+-+- 753 R flag: If the 'R' flag is set, the network supports only the 754 reactive handover mode. Otherwise, the network 755 supports both the predictive and reactive fast 756 handover mode. 758 7. Security Considerations 760 The security considerations for Mobile IPv6 fast handover are 761 described in [3]. When a 3G CDMA network is considered, it can be 762 assumed that the PAR and the NAR have a trust relationship and the 763 links between them and those between the ARs and the MN are secured. 764 The MN is authenticated every time it attaches to the new link; 765 therefore the AR can securely identify the MN. Depending on the 766 operator's policy, however, SEND [17] and the shared handover key 767 defined in [16] can also be applied. 769 8. IANA Considerations 771 This document defines two new IPv6 Neighbor Discovery options that 772 need to be assigned from the same space as the IPv6 Neighbor 773 Discovery Options defined in [18] 775 TBD1: Handover Assist Information Option (Section 6.1) 777 TBD2: MN ID option (Section 6.2) 779 This document requires two new registries to be created for the 780 Option-Code field in the Handover Assist Information Option and that 781 in the Mobile Node Identifier Option. The values for the Option-Code 782 must be within the range 0-255. New values for both registries can 783 be allocated by Standards Action or IESG approval. 785 The Option-Code values that need to be assigned by IANA are as 786 follows: 788 Option-Code for Handover Assist Information Option 789 Value Description Reference 790 ----- ---------------------------- ---------- 791 0 Reserved 792 1 ANID Section 6.1 793 2 Sector ID Section 6.1 795 Option-Code for Mobile Node Identifier Option 796 Value Description Reference 797 ----- ---------------------------- ---------- 798 0 Reserved 799 1 NAI Section 6.2 800 2 IMSI Section 6.2 802 9. Acknowledgements 804 The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved 805 Kafle and Vijay Devarapalli for providing feedback and support for 806 this work. The authors would also thank Sebastian Thalanany for 807 3GPP2 expert review. 809 10. References 811 10.1. Normative References 813 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 814 Levels", BCP 14, RFC 2119, March 1997. 816 [2] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 818 [3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", 819 draft-ietf-mipshop-fmipv6-rfc4068bis-06.txt, February 2008. 821 [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 822 Access Identifier", RFC 4282, December 2005. 824 [5] ITU-T Recommendation, "The international identification plan 825 for mobile terminals and mobile users", ITU-T E.212, May 2004. 827 10.2. Informative References 829 [6] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", 830 RFC 4260, November 2005. 832 [7] 3GPP2 TSG-C, "cdma2000 High Rate Packet Data Air Interface 833 Specification", C.S0024-A v.2.0, July 2005. 835 [8] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability 836 Specification", A.S0001-A v.2.0, June 2001. 838 [9] 3GPP2 TSG-A, "Interoperability Specification for High Rate 839 Packet 1 2 Data (HRPD) Access Network Interfaces - Rev A.", 840 A.S0007-A v.2.0, May 2003. 842 [10] 3GPP2 TSG-A, "Interoperability Specification (IOS) for High 843 Rate Packet Data (HRPD) Access Network Interfaces", 3GPP2 844 A.S0008-0 v3.0, May 2003. 846 [11] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP 847 and Mobile IP services", X.S0011-002-D v.1.0, February 2006. 849 [12] Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury, 850 "Mobile IPv6 Bootstrapping for the Authentication Option 851 Protocol", 852 draft-devarapalli-mip6-authprotocol-bootstrap-03.txt, 853 September 2007. 855 [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 856 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 857 RFC 4140, August 2005. 859 [14] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 860 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 861 January 2005. 863 [15] Gundavell, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., 864 and B. Patil, "Proxy Mobile IPv6", 865 draft-ietf-netlmm-proxymip6-10.txt, February 2008. 867 [16] Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6 868 Handover Key using SEND", 869 draft-ietf-mipshop-handover-key-03.txt, November 2007. 871 [17] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 872 Neighbor Discovery (SEND)", RFC 3971, March 2005. 874 [18] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 875 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 876 September 2007. 878 [19] Aboba, B., "Architectural Implications of Link Indications", 879 RFC 4907, June 2007. 881 Authors' Addresses 883 Hidetoshi Yokota 884 KDDI Lab 885 2-1-15 Ohara, Fujimino 886 Saitama, 356-8502 887 JP 889 Phone: +81 49 278 7894 890 Fax: +81 49 278 7510 891 Email: yokota@kddilabs.jp 893 Gopal Dommety 894 Cisco Systems, Inc. 895 170 West Tasman Drive 896 San Jose, CA 95134 897 US 899 Phone: +1 408 525 1404 900 Email: gdommety@cisco.com 902 Full Copyright Statement 904 Copyright (C) The IETF Trust (2008). 906 This document is subject to the rights, licenses and restrictions 907 contained in BCP 78, and except as set forth therein, the authors 908 retain all their rights. 910 This document and the information contained herein are provided on an 911 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 912 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 913 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 914 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 915 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Intellectual Property 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be 927 found in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this 933 specification can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org. 942 Acknowledgment 944 Funding for the RFC Editor function is provided by the IETF 945 Administrative Support Activity (IASA).