idnits 2.17.1 draft-yokota-mipshop-3gfh-02.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 on line 1244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1234. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: (e) The MN establishes the link layer connection. Since the IP address of the MN is guaranteed to be unique, the MN SHOULD not perform DAD == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To indicate the PAR to buffer packets destined for the PCoA, in (c), the MN SHOULD not include information on the NCoA in the FBU and the PAR SHOULD accept it. Or, when the PAR is indicated that the session with the MN has been closed by the lower layer signaling when the PAR attempts to send the FBAck, the PAR MAY start buffering. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As shown in this example, since the NCoA is assigned on the link with LLA2 and the NAR has the neighbor cache entry (NCE) for the NCoA, there is no need to send the HI from the PAR. To suppress sending the HI, a new flag 'N' is defined in the FBU. Also, to indicate the PAR to bi-cast packets, a new flag 'S' is defined in the FBU. If the MN requests selective bi-casting and the valid NCoA has been assigned, the MN SHOULD send the FBU to the PAR with the S flag set and the N flag unset requesting bi-casting but not sending the HI. If the PAR receives this FBU, it SHOULD not send the HI to the NAR. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (g) The PAR sends the HI to the NAR. The 'U' bit MUST not be set if the 'S' bit of the FBU is set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (g) The HA sends the HI to the NAR. The 'U' bit MUST not be set if the 'S' bit of the FBU is set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: N: Indication to send the HI. On the condition that the 'S' bit is set, if the 'N' bit is set, the receiver (the PAR or the HA) SHOULD send the HI to the NAR, otherwise the receiver SHOULD not send the HI. If the 'S' bit is not set, the 'N' bit MUST be ignored. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This option MUST be understood by the sender (typically the MN) and the receiver (typically the AR or the HA). If nodes in between do not support this option, they SHOULD treat this option as opaque and MUST not drop it. -- 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 (February 2006) is 6635 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: '4' is defined on line 1170, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 4068 (ref. '3') (Obsoleted by RFC 5268) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2153 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 3344 (ref. '8') (Obsoleted by RFC 5944) == Outdated reference: A later version (-06) exists of draft-elmalki-mobileip-bicasting-v6-05 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 3775 (ref. '10') (Obsoleted by RFC 6275) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 12 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 R&D Laboratories, Inc. 4 Expires: August 5, 2006 G. Dommety 5 Cisco Systems, Inc. 6 February 2006 8 Mobile IPv6 Fast Handovers for 3G CDMA Networks 9 draft-yokota-mipshop-3gfh-02.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 August 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 provider networks. However, this handover procedure requires 46 not only movement detection, but also the acquisition of a new 47 care-of address and the sending of a binding update message to the 48 home agent before the traffic begins to direct to the new location. 50 During this period, packets destined for the mobile node will be 51 lost, which may not be acceptable for real-time application such as 52 Voice over IP (VoIP) or video telephony. This document specifies 53 fast handover methods and selective bi-casting methods in the 3G 54 context in order to reduce latency and packet loss during handover. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Network reference model for Mobile IPv6 over 3G networks . . . 6 62 5. Fast handover procedures . . . . . . . . . . . . . . . . . . . 10 63 5.1 Predictive fast handover . . . . . . . . . . . . . . . . . 10 64 5.2 Reactive fast handover . . . . . . . . . . . . . . . . . . 14 65 6. Selective bi-casting . . . . . . . . . . . . . . . . . . . . . 18 66 6.1 Bi-casting by the PAR to the MN with multiple 67 interfaces (A-1) . . . . . . . . . . . . . . . . . . . . . 20 68 6.2 Bi-casting by the HA to the MN with multiple 69 interfaces (A-2) . . . . . . . . . . . . . . . . . . . . . 21 70 6.3 Bi-casting by the PAR to the MN with a single 71 interface (B-1) . . . . . . . . . . . . . . . . . . . . . 22 72 6.4 Bi-casting by the HA to the MN with a single 73 interfaces (B-2) . . . . . . . . . . . . . . . . . . . . . 24 74 6.5 Message Format . . . . . . . . . . . . . . . . . . . . . . 26 75 6.5.1 Simultaneous bindings flag and the HI message 76 indication flag extensions to (F)BU message . . . . . 26 77 6.5.2 New mobility option for bi-casting lifetime . . . . . 27 78 6.5.3 New status code for simultaneous bindings . . . . . . 27 79 6.5.4 New Option for vendor-specific information . . . . . . 28 80 6.6 MN and AR/HA operations . . . . . . . . . . . . . . . . . 29 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 82 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 85 Intellectual Property and Copyright Statements . . . . . . . . 33 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [1]. 93 2. Introduction 95 Mobile IPv6 allows mobile nodes (MNs) to maintain persistent IPv6 96 addresses while roaming around in IPv6 networks and it is adopted in 97 3G CDMA networks for handing off between different access provider 98 networks [2]. During handover, however, the mobile node (MN) needs 99 to switch the radio networks, to obtain a new Care-of Address (CoA) 100 and to re-register with the home agent (HA), which causes a 101 communication disruption. This is not desirable for real-time 102 applications such as VoIP and video telephony. To reduce this 103 disruption time or latency, a fast handover protocol for Mobile IPv6 104 [3] is proposed. In this proposal, there are two modes called 105 "predictive" fast handover and "reactive" fast handover. This 106 document first specifies how these fast handover modes can be applied 107 in the 3G context and shows that several Mobile IPv6 bootstrapping 108 procedures can be omitted. If the MN has more than one network 109 interface, even smoother handover can be realized by transmitting 110 packets destined for the MN to both networks, where the mobile node 111 resides and will move to. This document defines this mechanism as 112 selective bi-casting and shows several use cases with their handover 113 procedures. 115 3. Terminology 117 This document refers to [2] for Mobile IPv6 fast handover 118 terminology. Terms that first appear in this document are defined 119 below: 121 Forward Pilot Channel: 122 A portion of the Forward Channel that carries the pilot. The 123 Forward Channel is a portion of the physical layer channels 124 transmitted from the access network to the MN. 126 Sector: 127 Part of the access network that provides one CDMA channel. The 128 area covered by one base station may be split into several 129 sectors. 131 Home Link Prefix (HLP): 132 The prefix address assigned to the home link where the MN should 133 send the binding update message. This is one of the bootstrap 134 parameters for the MN. 136 Packet Data Serving Node (PDSN): 137 An entity that routes MN originated or MN terminated packet data 138 traffic. A PDSN establishes, maintains and terminates link 139 layer sessions to MNs [2]. A PDSN can be the access router in 140 the visited access provider network. 142 4. Network reference model for Mobile IPv6 over 3G networks 144 Figure 1 shows a simplified reference model of the Mobile IP enabled 145 3G networks. The home agent (HA) of the mobile node (MN) resides in 146 the home IP network and the MN roams around the access provider 147 networks. The home network and the access provider networks are 148 managed by either the same or different operator(s). Prior to the 149 Mobile IPv6 registration, the MN establishes a link-layer connection 150 with the access router (AR), which is also called PDSN (Packet Data 151 Serving Node) in 3G networks, of the access provider network to which 152 the MN is attached. When the MN moves from one access provider 153 network to another, a Mobile IPv6 handover is performed. The figure 154 shows the situation, where the MN moves from the PAR (previous access 155 router) to the NAR (new access router) and in the case of 3G 156 networks, the PAR and the NAR are equivalent to the oPDSN (old PDSN) 157 and the nPDSN (new PDSN). 159 Home IP Network 160 +........................+ 161 . +--------+ +--------+ . 162 . | HA |--| AAA | . 163 . +--------+ +--------+ . 164 +../......\..............+ 165 / \ 166 Access Provider Network Access Provider Network 167 +.............+ +.............+ 168 . +---------+ . . +---------+ . 169 . | PAR | . . | NAR | . 170 . | (oPDSN) | . . | (nPDSN) | . 171 . +---------+ . . +---------+ . 172 . | :| . . :| | . 173 . | :|L2link L2link:| | . 174 . | :| . . :| | . 175 . +--+ +:--+ . . +:--+ +--+ . 176 . |BS| |:BS| . . |:BS| |BS| . 177 . +--+ +:--+ . . +:--+ +--+ . 178 . :| . . :| . 179 . +----+ . . +----+ . 180 . | MN |---------> | MN | . 181 . +----+ . . +----+ . 182 +.............+ +.............+ 184 Figure 1: Reference Model for Mobile IP 186 In 3G CDMA networks, pilot channels transmitted by base stations 187 allow the MN to obtain a rapid and accurate C/I (carrier to 188 interference) estimate. This estimate is based on measuring the 189 strength of the Forward Pilot Channel or the pilot, which is 190 associated with a sector of a base station (BS). The MN searches for 191 the pilots and maintains those with sufficient signal strength in the 192 pilot sets. The MN sends measurement results, which include the 193 offsets of the PN (pseudorandom) code in use and the C/Is in the 194 pilot sets, to provide the access network (AN) with the estimate of 195 sectors in its neighborhood. There are several triggers for the MN 196 to send those estimates, e.g. when the strength of a pilot in the 197 pilot sets is higher enough than that of the current pilot, the MN 198 sends the estimates to the access network. If the serving access 199 network finds that the sector associated with the highest pilot 200 strength belongs to a different AR, it attempts to close the 201 connection with the MN. The MN then attempts to get a new traffic 202 channel assigned in the new access network, which is followed by 203 establishing a new connection with the new AR. The MN can 204 continually search for pilots without disrupting the data 205 communication and a timely handover is assisted by the network. If 206 the air interface information can be used as a trigger for the 207 handover between access routers, fast and smooth handover of Mobile 208 IPv6 can be realized in 3G CDMA networks. 210 To assist the handover of the MN to the new AR, various types of 211 information can be considered: the pilot sets, which include the 212 candidates of the target sectors or BSs, the cell information where 213 the MN resides, the serving nodes in the radio access network and the 214 location of the MN if available. In this document, a collection of 215 such information is called "handover assist information". In 3G 216 networks, the link-layer address of the new access point defined in 217 [3] may not be available. If this is the case, the handover assist 218 information SHOULD be used instead. 220 Figure 2 shows the protocol sequence from the attachment to the 221 network to the Mobile IPv6 registration. After the traffic channel 222 is assigned, the MN first establishes a link-layer connection between 223 itself and the access router. As the link-layer protocol, PPP can be 224 considered and in this figure, a PPP handshake is depicted as an 225 example. Then the MN registers with the HA by sending a Binding 226 Update message. There are several parameters for using Mobile IPv6 227 such as the home address (HoA), the care-of address (CoA), the home 228 agent address (HA) and the home link prefix (HLP). These addresses 229 are required prior to sending a Binding Update and obtaining these 230 values is called bootstrapping. One such method is proposed in [5], 231 where the bootstrapping information is obtained during the link-layer 232 establishment phase. 234 MN AR HA AAA 235 +-- | (PDSN) | | 236 | | LCP | | | 237 |(1) |<-------------------->| | | 238 | | CHAP or PAP | Access-Request/Accept | 239 |(2) |<-------------------->|<---------|----------------->| 240 | | +------------+ | | | 241 |(3) | | HA,HLP,HoA |<--+ | | 242 | | +------------+ | | 243 | | IPv6CP(IF-ID) | | | 244 |(4) |<--------|----------->| | | 245 (a)< +---------+ | | | | 246 |(5) | LL-addr |<--+ | | | 247 | +---------+ | | | 248 | | RA(prefix) | | | 249 |(6) |<-----|---------------| | | 250 | +-----+ | | | | 251 |(7) | CoA |<--+ | | | 252 | +-----+ | | | 253 | | DHCPv6(HA,HLP,HoA) | | | 254 |(8) |<-----------|-------->| | | 255 | +------------+ | | | | 256 |(9) | HA,HLP,HoA |<--+ | | | 257 | +------------+ | | | 258 *-- | | BU | | 259 (b) |------------------------------------>|Authentication| 260 | | | query/reply | 261 (c) | | |<------------>| 262 | | BA | | 263 (d) |<------------------------------------| | 264 | | | | 266 Figure 2: MIPv6 operation in 3G network 268 The procedure for the initial registration is as follows: 270 (a) The link-layer connection establishment and the bootstrapping 271 phase 273 (a-1) The LCP configure-request/response messages are exchanged. 275 (a-2) CHAP or PAP authentication is conducted. 277 (a-3) The bootstrapping parameters are conveyed from the HA and 278 stored in the AR (PDSN). 280 (a-4) Unique interface IDs are negotiated in IPv6CP. 282 (a-5) The MN configures its link-local address based on the 283 obtained interface ID. 285 (a-6) A router advertisement containing the prefix is received by 286 the MN. 288 (a-7) The MN configures its CoA based on the obtained prefix. 290 (a-8) DHCPv6 is used to obtain the bootstrap parameters such as 291 the home agent address, the home link prefix and the home address. 293 (a-9) The MN configures its HoA based on the obtained parameters. 295 (b) A binding update is sent to the HA. 297 (c) The HA asks the AAA to authenticate the MN for the initial 298 registration. 300 (d) The binding acknowledgment is sent back to the MN. 302 As is shown in Figure 2, it takes a considerable amount of time to 303 establish a link-layer connection and all of the above sequences run 304 every time the MN attaches to a new access network. It is therefore 305 beneficial if packets on the fly to the MN are saved not only during 306 the time period where the MN switches to the new radio channel but 307 also during the time period where the MN establishes the link-layer 308 connection. 310 5. Fast handover procedures 312 There are two modes defined in [3] according to the timing of sending 313 FBU (Fast Binding Update); one is called "predictive mode," where the 314 MN sends FBU and receives FBAck (Fast Binding Ack) on PAR (Previous 315 Access Router)'s link and the other is called "reactive mode," where 316 the MN sends FBU from NAR (New Access Router)'s link. In the 317 predictive mode, the time and place the MN hands off is indicated 318 sufficiently before the time it actually happens. In cellular 319 systems, handovers are controlled by the network and the predictive 320 mode is well applied although the reactive mode is possible as well. 321 On the other hand, in wireless LAN networks, for example, the MN 322 controls its handover and it is not easy to know where it moves to 323 until it starts to scan the channels. In this case, the reactive 324 mode is well applied. 326 5.1 Predictive fast handover 328 Figure 3 shows the predictive mode of MIPv6 fast handover operation. 329 When the MN finds a sector or a BS whose pilot signal is sufficiently 330 strong, it initiates handover according to the following sequence: 332 (a) A router solicitation for proxy router advertisement is sent 333 to the PAR. 335 (b) A proxy router advertisement containing the prefix in the NAR 336 is sent back to the MN. 338 (c) The MN creates an NCoA (new CoA) and sends the Fast Binding 339 Update (FBU) storing the NCoA to the PAR, which in turn sends the 340 Handover Initiate (HI) to the NAR. 342 (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR, 343 which in turn sends the FBU acknowledgment (FBAck) to the MN. 345 (e) The PAR starts forwarding packets toward the NCoA and the NAR 346 captures and buffers them. 348 (f) The connection associated with the PAR is closed and the 349 traffic channel is assigned in the new access network. 351 (g) The MN establishes the link layer connection with or without 352 authentication. 354 (h) The MN sends the Fast Neighbor Advertisement (FNA). 356 (i) The NAR starts delivering packets to the MN. 358 (j) The MN sends the BU to the HA. 360 (k) The HA sends the BA back to the MN. 362 (l) The HA starts delivering packets to the MN via the NAR. 364 MN PAR NAR HA AAA 365 | RtSolPr | | | | 366 (a) |------------->| | | | 367 | PrRtAdv | | | | 368 (b) |<-------------| | | | 369 | FBU | Hl | | | 370 (c) |------------->|-------------->| | | 371 | FBack | HAck | | | 372 (d) |<-------------|<--------------| | | 373 | |forward packets| | | 374 (e) | |==============>| | | 375 | | +-----------+ | | 376 | | | buffering | | | 377 | | +-----------+ | | 378 (f) handover | | | | 379 | | link layer connection | | 380 (g) |/----------------------------\|/...........................\| 381 |\----------------------------/|\.........................../| 382 | FNA | | | 383 (h) |----------------------------->| | | 384 | deliver packets | | | 385 (i) |<=============================| | | 386 | | BU | | | 387 (j) |-------------------------------------------->| | 388 | | BA | | | 389 (k) |<--------------------------------------------| | 390 | deliver packets | | | 391 (l) |<=============================|<=============| | 393 Figure 3: MIPv6 Fast handover operation (predictive mode) 395 It is assumed that the NAR can be identified by the PAR leveraging 396 the handover assist information from the MN. To perform the 397 predictive mode, the FBAck MUST be received by the MN before the 398 connection with the current access network is closed. If the MN 399 fails to send the FBU before handover, it SHOULD fall back to the 400 reactive mode. Even if the MN successfully sends the FBU, its 401 reception by the PAR may be delayed for various reasons such as 402 congestion. If the NAR receives the HI triggered by the delayed FBU 403 after the reception of the FNA ((c) comes after (h)), then the NAR 404 SHOULD send the HAck with handover not accepted. 406 In (a), RtSolPr MUST include the MN and the New Access Point Link- 407 Layer Address (LLA) options according to [3]. As for the MN-LLA 408 option, the only available identifier is the interface ID, so it 409 SHOULD be used for the MN-LLA. As for the New AP-LLA, the handover 410 assist information may be applied. Since the LLA is assumed to be an 411 IEEE identifier, even if the length field of the LLA option is in 412 units of 8 octets, the actual length can be obtained by knowing that 413 the length of an IEEE identifier is 6 octets. If the interface ID of 414 the MN is generated in the EUI-64-based format, the MN-LLA can be 415 constructed from it. However, if the LLA is not well-known, the 416 length of the LLA becomes ambiguous. If this is the case, it is 417 necessary to use a new option defined in Section 6.5.4 and the 418 corresponding length in it. 420 In (b), PrRtAdv MUST include options for the LLA, IP address and 421 prefix of the NAR. The PAR SHOULD be able to identify the NAR from 422 the handover assist information provided by the MN. 424 There are several ways to configure a unique IP address for the MN. 425 If a globally unique prefix is assigned per each link as introduced 426 in [5], the MN can use any interface ID except that of the other peer 427 to create a unique IP address. If this is the case, however, the PAR 428 cannot provide the MN with a correct prefix for the new network since 429 such a prefix is selected by the NAR and provided in the router 430 advertisement ((a-6) in Figure 2). Still, the NCoA MUST be included 431 in the FBU for the PAR to resolve the IP address of the NAR, so that 432 the MN configures a temporary NCoA with the prefix of the NAR and the 433 correct NCoA MUST be assigned by the NAR. Therefore, in (c), the PAR 434 MUST send the HI with the S flag set when it receives the FBU from 435 the MN. On the other hand, if more than one MN connected to an AR 436 share the same prefix, each MN MUST have a unique interface ID. 437 Unless it is guaranteed that each MN connected to the network 438 including a roaming case is preconfigured with a unique interface ID, 439 it MUST be agreed or provided by the NAR via the HI/Hack exchange. 441 In [3], the FNA MUST include the LLA of the MN, but the point-to- 442 point link layer connection makes it unnecessary. The only required 443 information is the NCoA to check if there is a corresponding buffer, 444 thus in (h), the function of the FNA can be realized in several ways. 446 o Since the establishment of the link layer connection in (g) 447 indicates readiness of data communication on the MN side, the NAR 448 immediately checks if there is a buffer that has packets destined 449 for the NCoA and starts delivering if any. (elimination of FNA) 451 o The FNA equivalent information can be conveyed in the phase of the 452 link layer connection, e.g. by conveying the NCoA in a PPP IPCP 453 with vendor specific extension as defined in [6]. Only when this 454 message is received by the NAR, it checks if there is a buffer for 455 the NCoA. (L2 implementation of FNA) 457 o The MN sends the FNA as defined in [3] with the LLA of the MN, 458 which may be derived from the EUI-64 based interface ID. (standard 459 implementation of FNA) 461 When PPP IPCP option is used as the means for the L2 implementation 462 of FNA, it SHOULD be confirmed that the NAR supports this option, 463 otherwise it may cause a longer delay by the Configure-Reject 464 message. 466 The primary benefit of this mode is that the packets destined for the 467 MN can be buffered at the NAR, and packet loss due to handover will 468 be much lower than that of the normal MIPv6 opration. Regarding the 469 bootstrapping, the following benefits can be obtained, too: 471 o Since the HA, HLP and HoA are not changed during the fast 472 handover, bootstrapping information is not required. 474 o Since the NCoA including the interface ID can be obtained or 475 configured via the fast handover procedures, a router 476 advertisement is not required. 478 Therefore, as shown in Figure 4, bootstrapping procedures (a-3) to 479 (a-9) can be omitted from the standard MIPv6 operation in Figure 2. 480 Also, if the security policy permits, the NAR can know the MN by the 481 NAI in the PPP link setup and the authentication in (2) may be 482 omitted. Note that another authentication is conducted in the MIPv6 483 registration phase and presumably the same AAA is referred to. 485 MN oPDSN nPDSN HA AAA 486 +-- | (PAR) (NAR) | | 487 | | LCP | | | | 488 | (1) |<----------------------->| | | 489 | | CHAP | | Access-Request/Accept | 490 | (2) |<----------------------->|<-------|------------->| 491 |+...................................+ | | | 492 |. | +------------+ | . | | | 493 |.(3)* | | HA,HLP,HoA |<------------+ | | 494 |. | +------------+ | . | | 495 |. | | . | | 496 |. | IPv6CP(IF-ID) | . | | 497 |.(4)* |<---------|------------->| . | | 498 (a)< . +---------+ | | | . | | 499 |.(5)*| LL-addr |<-+ | | . | | 500 |. +---------+ | | . | | 501 |. | | . | | 502 |. | RA(prefix) | . | | 503 |.(6)* |<---------|--------------| . | | 504 |. +-----+ | | | . | | 505 |.(7)*| CoA |<-----+ | | . | | 506 |. +-----+ | | . | | 507 |. | | . | | 508 |. | HCPv6(HA,HL,HoA) | . | | 509 |.(8)* |<---------|------------->| . | | 510 |. +-----+ | | | . | | 511 |.(9)*| HoA |<-----+ | | . | | 512 |. +-----+ | | . | | 513 |+...................................+ | | 514 *-- | | | | | 516 Figure 4: Procedures that can be omitted in the link-layer connection 518 5.2 Reactive fast handover 520 When the MN cannot receive the FBAck on the PAR's link or the network 521 does not support the predictive fast handover, the reactive fast 522 handover can be applied. To support the predictive fast handover, 523 the PAR must accurately resolve the address of the NAR from the lower 524 layer information such as the link-layer address of the new access 525 point or the base station, which is not always feasible in some 526 cases. To minimize packet loss in this situation, the PAR instead of 527 the NAR can buffer packets for the MN until the MN regains 528 connectivity with the NAR. The NAR obtains the information of the 529 PAR from the MN on the NAR's link and receives packets buffered at 530 the PAR. In this case, the PAR does not need to know the IP address 531 of the NAR or the NCoA and just waits for the NAR to contact the PAR. 533 However, since the PAR needs to know when to buffer packets for the 534 MN, the PAR obtains the timing of buffering from the MN via the FBU 535 or the lower layer signaling, e.g. an indication of the release of 536 the connection with the MN. Details of the procedure are as follows: 538 (a) A router solicitation for proxy router advertisement MAY be 539 sent to the PAR. 541 (b) The proxy router advertisement MAY be sent to the MN, but the 542 prefix of the NAR MAY not be included. 544 (c) The MN sends the FBU or the access network indicates the close 545 of the connection with the MN by the lower layer signaling. The 546 PAR MAY start buffering packets destined for the PCoA. 548 (d) The connection associated with the PAR is closed and the 549 traffic channel is assigned in the new access network. 551 (e) The MN establishes the link layer connection. Since the IP 552 address of the MN is guaranteed to be unique, the MN SHOULD not 553 perform DAD 555 (f) The MN sends the Fast Binding Update (FBU) to the NAR either 556 or not being encapsulated by the Fast Neighbor Advertisement 557 (FNA). 559 (g) The NAR decapsulates the FBU if encapsulated and sends it to 560 the PAR. 562 (h) The PAR sends the Handover Initiate (HI) to the NAR with the 563 Code set to 1. 565 (i) The NAR sends the Handover Acknowledge (HAck) back to the PAR. 567 (j) The PAR sends the FBAck to the NAR. 569 (k) If the PAR buffers packets destined for the PCoA, it starts 570 forwarding them as well as newly arriving ones to the NAR. 572 (l) The NAR delivers the packets to the MN. 574 (m) The MN sends the BU to the HA. 576 (n) The HA sends the BA back to the MN. 578 (o) The HA starts delivering packets to the MN via the NAR. 580 MN oPDSN nPDSN HA AAA 581 | (PAR) (NAR) | | 582 | RtSolPr | | | | 583 (a) |------------->| | | | 584 | PrRtAdv | | | | 585 (b) |<-------------| | | | 586 | FBU/lower-layer sig. | | | 587 (c) | . . . . . . >| | | | 588 | +-----------+ | | | 589 | | buffering | | | | 590 | +-----------+ | | | 591 (d) handover | | | | 592 | | link layer connection | | 593 (e) |/----------------------------\|/...........................\| 594 |\----------------------------/|\.........................../| 595 | FNA[FBU]/FBU | | | 596 (f) |----------------------------->| | | 597 | | FBU | | | 598 (g) | |<--------------| | | 599 | | HI | | | 600 (h) | |-------------->| | | 601 | | HAck | | | 602 (i) | |<--------------| | | 603 | | FBack | | | 604 (j) | |-------------->| | | 605 | |forward packets| | | 606 (k) | |==============>| | | 607 | deliver packets | | | 608 (l) |<=============================| | | 609 | | BU | | | 610 (m) |-------------------------------------------->| | 611 | | BA | | | 612 (n) |<--------------------------------------------| | 613 | deliver packets | | | 614 (o) |<=============================|<=============| | 616 Figure 5: MIPv6 Fast handover operation (reactive mode) 618 To indicate the PAR to buffer packets destined for the PCoA, in (c), 619 the MN SHOULD not include information on the NCoA in the FBU and the 620 PAR SHOULD accept it. Or, when the PAR is indicated that the session 621 with the MN has been closed by the lower layer signaling when the PAR 622 attempts to send the FBAck, the PAR MAY start buffering. 624 An L2-based fast handover is possible as defined in [7] by extending 625 the L2 link from the previous access network to the new access 626 network via the PAR and the NAR. The timing of the fast handover 627 trigger is the same as the reactive fast handover method (without 628 buffering) in this section. In the case of the L2-based fast 629 handover, however, once the L2 link is extended to the new location, 630 it is maintained until the MN becomes inactive (dormant) and the link 631 is released. As long as the L2 link is extended, the path, on which 632 packets are conveyed, is not optimal in length. In the case of 633 Mobile IPv6 fast handover, when the new location is registered with 634 the HA, the packets are directed to the NAR. 636 6. Selective bi-casting 638 If the MN has the capability to receive more than one radio signal, 639 even smoother handover can be realized. This situation happens when, 640 for instance, the MN can receive multiple channels of the same radio 641 system at the same time, or the MN has multiple interfaces of 642 different radio systems such as 3G and WiFi. Especially, when the MN 643 is running a real-time and interactive application, long-time 644 buffering at the PAR or NAR is not always beneficial for the MN. If 645 this is the case, it will be helpful to deliver packets destined for 646 the MN via both the old and new points of attachment at the same time 647 during handover. Even if the MN has only a single interface, the 648 above function has some benefits when the timing of handover cannot 649 be acquired precisely in advance. This type of use case was 650 originally proposed in [9]. Mobile IPv4 allows simultaneous bindings 651 [8] and bi-casting is realized by retaining the old care-of address 652 in the binding cache and sending packets destined for the MN towards 653 both the old and new care-of addresses. Since bi-casting consumes 654 double the network resources, it must be limited to smooth handover. 655 In this document, bi-casting used for a short period of time for 656 smooth handover is called "selective bi-casting." Figure 6 shows 657 that the simultaneous bindings and bi-casting are performed at the 658 PAR, which copies packets destined for the MN and transmits them not 659 only to the old point of attachment but also to the new point of 660 attachment via the NAR. The above operation is more effective when 661 the predictive fast handover is applied because in the case of the 662 reactive fast handover, all the actions are taken after the MN has 663 moved to the new location. By that time, it is not necessary to 664 deliver packets to the old point of attachment. As another scenario, 665 Figure 7 shows that simultaneous bindings are performed at the HA. 666 This scenario is likely to happen when the MN is connected to 667 multiple different networks such as 3G and WiFi at the same time. 668 Also, if the access networks in Figure 1 are operated by different 669 providers, it may be difficult for the ARs in these networks to 670 cooperate with each other. In this case as well, the HA must handle 671 simultaneous bindings and bi-casting. 673 +----------+ 674 | HA | 675 +----------+ 676 / 677 / 678 +------/-+ +--------+ 679 | PAR --|------|-- NAR | 680 +------|-+ +-|------+ 681 | | 682 | | 683 +----|+ +|----+ 684 | BS || || BS | 685 +----|+ +|----+ 686 \ / 687 \ | / 688 > |< 689 +------+ 690 | MN |--> 691 +------+ 693 Figure 6: Selective bi-casting scenario 1 695 +----------+ 696 | HA | 697 +----------+ 698 / \ 699 / \ 700 +------/-+ +-\------+ 701 | PAR | | | | NAR | 702 +------|-+ +-|------+ 703 | | 704 | | 705 +----|+ +|----+ 706 | BS || || BS | 707 +----|+ +|----+ 708 \ / 709 \ | / 710 > |< 711 +------+ 712 | MN |--> 713 +------+ 715 Figure 7: Selective bi-casting scenario 2 717 From the above observations, selective bi-casting can be categorized 718 from the following viewpoints: 720 [No. of interfaces on the MN] 721 (A) multiple interfaces 722 (B) single interface 724 [the node where bi-casting is performed] 725 (1) at the PAR 726 (2) at the HA 728 The procedures for each combination are described in the following 729 section. 731 6.1 Bi-casting by the PAR to the MN with multiple interfaces (A-1) 733 As shown in Figure 8, the MN has two interfaces with the link layer 734 addresses: LLA1 and LLA2. This case is typical of handover between 735 different access systems such as 3G and WiFi. Details of the 736 sequence are as follows: 738 (a) The interface with LLA1 acquires the global IP address PCoA. 740 (b) The MN sends the BU to the HA from the link with PCoA with S=0 741 and N=0 (the default behavior), which are defined in 742 Section 6.5.1, and receives the BA from the HA. 744 (c) The MN receives packets destined for PCoA from the link with 745 LLA1 via the PAR. 747 (d) When the MN detects that handover is imminent, it opens the 748 interface with LLA2 and acquires the global IP address NCoA. 750 (e) The MN inserts NCoA into the FBU and sends it with S=1 and N=0 751 from the link with PCoA to the PAR. 753 (f) The MN receives the FBack from the PAR. 755 (g) The PAR sends packets destined for PCoA directly to the link 756 with LLA1 and also forwards them to the NAR. The forwarded 757 packets are received by the MN on the link with NCoA. 759 (h) When the MN is ready to use the link with LLA2 as the primary 760 one, it sends the BU to the HA with S=0 and N=0. 762 (i) The MN starts to receive packets via the NAR. 764 As shown in this example, since the NCoA is assigned on the link with 765 LLA2 and the NAR has the neighbor cache entry (NCE) for the NCoA, 766 there is no need to send the HI from the PAR. To suppress sending 767 the HI, a new flag 'N' is defined in the FBU. Also, to indicate the 768 PAR to bi-cast packets, a new flag 'S' is defined in the FBU. If the 769 MN requests selective bi-casting and the valid NCoA has been 770 assigned, the MN SHOULD send the FBU to the PAR with the S flag set 771 and the N flag unset requesting bi-casting but not sending the HI. 772 If the PAR receives this FBU, it SHOULD not send the HI to the NAR. 774 +..MN..+ 775 LLA1 LLA2 PAR NAR HA 776 | | | | | 777 |link-layer connection | | | 778 (a) |/--------------------\| | | 779 |\--------------------/| | | 780 | | BU(S=0,N=0)/BA | 781 (b) |<---------------------------------------------------------->| 782 | | | | | 783 (c) |<=====================|<====================================| 784 | | link-layer connection | | 785 (d) | |/--------------------------------\| | 786 | |\--------------------------------/| | 787 | FBU(S=1,N=0) | | | 788 (e) |--------------------->| | | 789 | FBack | | | 790 (f) |<---------------------| | | 791 | | | | | 792 (g) |<====================+|<====================================| 793 | | +=================>+| | 794 | |<================================+| | 795 | | | | | 796 | | BU(S=0,N=0)/BA | 797 (h) | |<--------------------------------------------------->| 798 : | | | | 799 (i) : |<=================================|<=================| 801 Figure 8: Combination (A-1) 803 6.2 Bi-casting by the HA to the MN with multiple interfaces (A-2) 805 This case happens when the access network where the PAR belongs and 806 the one where the NAR belongs are administrated by different 807 providers or are different access systems. The cellular network is 808 typically a closed network and the ARs can access external nodes only 809 via the HA. If this is the case, the PAR and the NAR cannot directly 810 communicate with each other. Details of the sequence of this case 811 are shown in Figure 9 and below: 813 (a) through (d) are the same as those in the case (A-1). 815 (e) The MN sends the BU to the HA from the link with NCoA with S=1 816 and N=0, which means that the MN requests the HA to bi-cast but 817 not to send the HI. 819 (f) The HA forwards packets destined for the MN to both the PAR 820 and the NAR. Those packets can be received by the MN on either 821 one or both of the links. 823 (g) When the bi-casting lifetime, which is defined in 824 Section 6.5.2, is expired, packets are forwarded only to the NAR. 826 +..MN..+ 827 LLA1 LLA2 PAR NAR HA 828 | | | | | 829 |link-layer connection | | | 830 (a) |/--------------------\| | | 831 |\--------------------/| | | 832 | | BU(S=0,N=0)/BA | | 833 (b) |<---------------------------------------------------------->| 834 | | | | | 835 (c) |<=====================|<====================================| 836 | | link-layer connection | | 837 (d) | |/--------------------------------\| | 838 | |\--------------------------------/| | 839 | | | | | 840 | | BU(S=1,N=0)/BA | 841 (e) | |<--------------------------------------------------->| 842 | | | | | 843 (f) |<=====================|<====================================| 844 | |<=================================|<=================| 845 : | | | | 846 (g) : |<=================================|<=================| 848 Figure 9: Combination (A-2) 850 6.3 Bi-casting by the PAR to the MN with a single interface (B-1) 852 This case is typical of handover with the same access system within 853 the same provider network. Details of the sequence of this case are 854 shown in Figure 10 and below: 856 (a) through (c) are the same as those in the case (A-1). 858 (d) The MN sends the RtSolPr to the PAR. 860 (e) The MN receives the PrRtAdv with a valid NCoA from the PAR. 862 (f) The MN sends the FBU with S=1 and N=1 to the PAR. 864 (g) The PAR sends the HI to the NAR. The 'U' bit MUST not be set 865 if the 'S' bit of the FBU is set. 867 (h) The PAR receives the HAck with a valid NCoA from the NAR. 869 (i) The PAR sends the FBack both to the MN and the NAR. 871 (j) The PAR sends packets destined for PCoA directly to the MN and 872 also forwards them to the NAR. 874 (k) The MN moves to the new access network and configures NCoA by 875 establishing the link-layer connection. At this point, the MN can 876 receive the forwarded packets from the NAR. 878 (l) The MN sends the BU with S=0 and N=0 to the HA. 880 (m) The MN starts to receive packets only via the NAR. 882 In (g), it is necessary that the PAR sends the HI to the NAR to 883 create the neighbor cache entry (NCE) for the NCoA on the NAR. 885 MN PAR NAR HA 886 | | | | 887 |link-layer connection | | | 888 (a) |/--------------------\| | | 889 |\--------------------/| | | 890 | BU(S=0,N=0)/BA | 891 (b) |<---------------------------------------------------------->| 892 | | | | 893 (c) |<=====================|<====================================| 894 | RtSoIPr | | | 895 (d) |--------------------->| | | 896 | PrRtAdv | | | 897 (e) |<---------------------| | | 898 | FBU(S=1,N=1) | | | 899 (f) |--------------------->| | | 900 | | HI | | 901 (g) | |----------------->| | 902 | (new link) | HAck | | 903 (h) | | |<-----------------| | 904 | | FBAck | FBack | | 905 (i) |<---------------------|----------------->| | 906 | | | | | 907 (j) |<====================+|<====================================| 908 |.....>| +=================>+| | 909 : |<================================+| | 910 : | | | | 911 : | link-layer connection | | 912 (k) : |/--------------------------------\| | 913 : |\--------------------------------/| | 914 : | BU(S=0,N=0)/BA | 915 (l) : |<--------------------------------------------------->| 916 : | | | | 917 (m) : |<=================================|<=================| 919 Figure 10: Combination (B-1) 921 6.4 Bi-casting by the HA to the MN with a single interfaces (B-2) 923 This case is typical of handover with the same access system between 924 different provider networks. Details of the sequence of this case 925 are shown in Figure 11 and below: 927 (a) through (d) are the same as those in the case (A-3). 929 (e) The MN receives the PrRtAdv without a valid NCoA from the PAR. 931 (f) The MN sends the FBU with S=1 and N=1 to the HA. 933 (g) The HA sends the HI to the NAR. The 'U' bit MUST not be set 934 if the 'S' bit of the FBU is set. 936 (h) The HA receives the HAck from the NAR. 938 (i) The HA sends the FBack to the MN and the NAR. 940 (j) The HA sends packets destined for the MN to both the PAR and 941 the NAR. They can be received by the MN on either one or both of 942 the links. 944 (k) The MN moves to the new access network and configures NCoA by 945 establishing the link-layer connection. At this point, the MN can 946 receive the forwarded packets from the NAR. 948 (l) The MN sends the BU with S=0 and N=0 to the HA. 950 (m) The MN starts to receive packets only via the NAR. 952 (k) The MN moves to the new access network and configures NCoA by 953 establishing the link-layer connection. At this point, the MN can 954 receive the forwarded packets from the NAR. 956 (l) The MN sends the BU with S=0 and N=0 to the HA. 958 (m) The MN starts to receive packets only via the NAR. 960 In (e), by receiving the PrRtAdv without a valid NCoA (the Code is 961 typically 2), the MN judges that the PAR does not have information on 962 the NAR or can not send the HI directly to the NAR. Then the MN 963 sends the FBU to the HA. 965 In (g), it is necessary that the HA sends the HI to the NAR to make 966 the NCE for the NCoA on the NAR. 968 MN PAR NAR HA 969 | | | | 970 |link-layer connection | | | 971 (a) |/--------------------\| | | 972 |\--------------------/| | | 973 | BU(S=0,N=0)/BA | 974 (b) |<---------------------------------------------------------->| 975 | | | | 976 (c) |<=====================|<====================================| 977 | RtSoIPr | | | 978 (d) |--------------------->| | | 979 | PrRtAdv | | | 980 (e) |<---------------------| | | 981 | FBU(S=1,N=1) | 982 (f) |----------------------------------------------------------->| 983 | | | HI | 984 (g) | | |<-----------------| 985 | | | HAck | 986 (h) | (new link) | |----------------->| 987 | | | | FBack | 988 (i) | | | FBack |<-----------------| 989 |<-----------------------------------------------------------| 990 | | | | | 991 (j) |<=====================|<====================================| 992 | |<=================================|<=================| 993 |.....>| link-layer connection | | 994 (k) : |/--------------------------------\| | 995 : |\--------------------------------/| | 996 : | BU(S=0,N=0)/BA | 997 (l) : |<--------------------------------------------------->| 998 : | | | | 999 (m) : |<=================================|<=================| 1001 Figure 11: Combination (B-2) 1003 6.5 Message Format 1005 6.5.1 Simultaneous bindings flag and the HI message indication flag 1006 extensions to (F)BU message 1008 When the MN requests simultaneous bindings and bi-casting to the HA 1009 or the PAR, the MN sets the newly defined simultaneous bindings flag 1010 in the Binding Update (BU) [10] or FBU, respectively. To suppress 1011 sending the HI when it is unnecessary, the HI message indication flag 1012 is defined in the (F)BU as well. 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Sequence # | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 |A|H|L|K|S|N| Reserved | Lifetime | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | | 1020 . . 1021 . Mobility options . 1022 . . 1023 | | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 S: Simultaneous bindings. If the 'S' bit is set, the mobile 1027 node is requesting that the HA or the PAR retain its prior 1028 mobility bindings and bi-cast packets destined for the MN. 1030 N: Indication to send the HI. On the condition that the 'S' 1031 bit is set, if the 'N' bit is set, the receiver (the PAR or 1032 the HA) SHOULD send the HI to the NAR, otherwise the 1033 receiver SHOULD not send the HI. If the 'S' bit is not 1034 set, the 'N' bit MUST be ignored. 1036 If the 'S' bit is supported, the 'N' MUST also be supported. When 1037 S=0 and N=0, the AR and the HA perform according to [3] and [10], 1038 respectively (the default behavior). 1040 6.5.2 New mobility option for bi-casting lifetime 1042 The MN may request how long the HA or the PAR should retain the 1043 simultaneous bindings (and therefore bi-casting) by attaching the 1044 following mobility option in the binding update message: 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Type = T.B.D | Length = 2 | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Bi-casting Lifetime | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 Bi-casting Lifetime: 1055 The time period when the PAR or the HA retains the previous 1056 CoA (PCoA). 1058 6.5.3 New status code for simultaneous bindings 1060 If the AR or the HA receives more (fast) binding update messages with 1061 different CoAs for the same HoA than it can support, it should send a 1062 binding acknowledgement message with the following status code: 1064 Status T.B.D. 1065 too many simultaneous mobility bindings 1067 6.5.4 New Option for vendor-specific information 1069 If the lower layer information of the new point of attachment is not 1070 represented as the Link-Layer Address, the following option SHOULD be 1071 used. The primary purpose of this option is to convey the handover 1072 assist information described in Section 4. 1074 0 1 2 3 1075 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 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Type | Length | Option-Code | VS-Length | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | VS-Value... 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 Type T.B.D. 1084 Length The size of this option in 8 octets including the 1085 Type, Length, Option-Code and VS-Length fields. 1087 Option-Code Indicates the particular type of vendor-specific 1088 information. This value is administrated by the 1089 vendor or organization that uses this option. 1091 VS-Length The size of the VS-Value field in octets. 1093 VS-Value Zero or more octets of vendor-specific information 1094 data. 1096 This option MUST be understood by the sender (typically the MN) and 1097 the receiver (typically the AR or the HA). If nodes in between do 1098 not support this option, they SHOULD treat this option as opaque and 1099 MUST not drop it. 1101 Depending on the size of the VS-Value field, appropriate padding MUST 1102 be used to ensure that the entire option size is a multiple of 8 1103 octets. The VS-Length is used to disambiguate the size of the VS- 1104 Value. 1106 6.6 MN and AR/HA operations 1108 In order to enable bi-casting, the MN sends a BU or FBU by setting 1109 the 'S' flag to the HA or the PAR, respectively. When the PAR/HA 1110 allows bi-casting, a successful (F)Back is returned and bi-casting is 1111 started. The MN can request a desirable bi-casting lifetime to the 1112 PAR/HA with the bi-casting lifetime option in the (F)BU. If the 1113 requested lifetime is acceptable, the PAR/HA sends an (F)Back with 1114 the accepted bi-casting lifetime, which is determined by the policies 1115 of the PAR/HA. When bi-casting is performed at the HA, the MN is 1116 likely to receive duplicate packets from multiple interfaces. In the 1117 case of audio or video applications, it may be necessary to 1118 synchronize the bi-cast flows coming from different access networks 1119 so that the user does not have to experience a communication 1120 disruption. This may take longer than just the time for a handover. 1121 If this is the case, the MN may request a longer bi-cast lifetime. 1122 After the flows are synchronized and successfully switched on the 1123 application level, the MN may explicitly de-register the PCoA by 1124 sending an (F)BU with the lifetime field being zero. On the side of 1125 the PAR/HA, the maximum value of the bi-casting lifetime must be 1126 configured and even if the MN does not request a bi-casting lifetime 1127 or does not successfully de-register the PCoA, it is deleted after 1128 the maximum value of the bi-casting lifetime elapses. 1130 7. Security Considerations 1132 The security considerations for Mobile IPv6 fast handover are 1133 described in [3]. When a 3G network is considered, the PAR and the 1134 NAR have a trusting relationship and the links between them and those 1135 between the ARs and the MN are usually secured. When the MN is 1136 authenticated at the phase of the link-layer connection, the AR can 1137 distinguish the authenticated users from the others. This may be not 1138 the case, however, if the access networks are operated by different 1139 providers. 1141 8. Conclusions 1143 The handover performance of the standard Mobile IPv6 is not 1144 sufficient for real-time communications that are not resilient to 1145 packet loss. The Mobile IPv6 fast handover methods are effective for 1146 these applications. This document specifies how these methods can be 1147 applied to 3G networks. By introducing fast handover, not only are 1148 more packets saved which otherwise would be dropped, but also some of 1149 the bootstrapping parameters can be omitted at the link establishment 1150 phase, which can expedite the handover process. For interactive 1151 real-time applications, in which excessive buffering is 1152 inappropriate, selective bi-casting is also proposed. By retaining 1153 the PCoA and the NCoA in the binding cache, packets destined for the 1154 MN are transmitted to both the old and new points of attachment at 1155 the same time, whereby the applications on the MN can choose which 1156 flow to adopt considering the media continuity. 1158 9. References 1160 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1161 Levels", BCP 14, RFC 2119, March 1997. 1163 [2] 3GPP2 TSG-A, "Interoperability Specification (IOS) for cdma2000 1164 Access Network Interfaces Part 1 Overview", A.S0011-C v.1.0, 1165 February 2005. 1167 [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068, 1168 July 2005. 1170 [4] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: 1171 Introduction", X.P0011-001-D v.0.5, November 2004. 1173 [5] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP 1174 and Mobile IP services", X.P0011-002-D v.0.5, November 2004. 1176 [6] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997. 1178 [7] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet 1179 Data Mobility and Resource Management", X.P0011-003-D v.0.5, 1180 November 2004. 1182 [8] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, 1183 August 2002. 1185 [9] Malki, K., "Simultaneous Bindings for Mobile IPv6 Fast 1186 Handovers", draft-elmalki-mobileip-bicasting-v6-05.txt, 1187 October 2003. 1189 [10] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 1191 Authors' Addresses 1193 Hidetoshi Yokota 1194 KDDI R&D Laboratories, Inc. 1195 2-1-15 Ohara, Fujimino 1196 Saitama, 356-8502 1197 JP 1199 Phone: +81 49 278 7894 1200 Fax: +81 49 278 7510 1201 Email: yokota@kddilabs.jp 1203 Gopal Dommety 1204 Cisco Systems, Inc. 1205 170 West Tasman Drive 1206 San Jose, CA 95134 1207 US 1209 Phone: +1 408 525 1404 1210 Email: gdommety@cisco.com 1212 Intellectual Property Statement 1214 The IETF takes no position regarding the validity or scope of any 1215 Intellectual Property Rights or other rights that might be claimed to 1216 pertain to the implementation or use of the technology described in 1217 this document or the extent to which any license under such rights 1218 might or might not be available; nor does it represent that it has 1219 made any independent effort to identify any such rights. Information 1220 on the procedures with respect to rights in RFC documents can be 1221 found in BCP 78 and BCP 79. 1223 Copies of IPR disclosures made to the IETF Secretariat and any 1224 assurances of licenses to be made available, or the result of an 1225 attempt made to obtain a general license or permission for the use of 1226 such proprietary rights by implementers or users of this 1227 specification can be obtained from the IETF on-line IPR repository at 1228 http://www.ietf.org/ipr. 1230 The IETF invites any interested party to bring to its attention any 1231 copyrights, patents or patent applications, or other proprietary 1232 rights that may cover technology that may be required to implement 1233 this standard. Please address the information to the IETF at 1234 ietf-ipr@ietf.org. 1236 Disclaimer of Validity 1238 This document and the information contained herein are provided on an 1239 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1240 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1241 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1242 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1243 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1244 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1246 Copyright Statement 1248 Copyright (C) The Internet Society (2006). This document is subject 1249 to the rights, licenses and restrictions contained in BCP 78, and 1250 except as set forth therein, the authors retain all their rights. 1252 Acknowledgment 1254 Funding for the RFC Editor function is currently provided by the 1255 Internet Society.