idnits 2.17.1 draft-cui-mobopts-hcf-wlan-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 690. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: Here we refer to the Bi-cast/N-cast draft [7] lifetime mechanism, the HCF MUST create a new binding cache sub-entry (linked to the original entry for the old CoA) for the MN's new CoA. This sub-entry contains the same fields as normal binding cache entries but it MUST not replace any existing entries for the MN. The new sub-entry will have two lifetimes instead of one: the normal new CoA BU lifetime (sent in the BA) and a Bicasting lifetime set to SHORT_BINDING_LIFETIME (sent in the BA sub-option). The new CoA lifetime runs in parallel with the Bicasting lifetime. Until the Bicasting lifetime expires, the HCF MUST send a copy of the data destined for the MN to the old CoA and to the new CoA in the linked binding cache sub-entry or sub-entries. When the Bicasting lifetime expires, the HCF MUST remove the bicasting lifetime field and replace the old binding cache entry for the old CoA with the new CoA sub-entry. As a result, the HCF will end up with one entry for the MN's new CoA with the remaining new CoA lifetime. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6863 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: '2' is defined on line 601, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 604, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 609, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 612, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 616, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 624, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 627, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-elmalki-mobileip-bicasting-v6-05 == Outdated reference: A later version (-01) exists of draft-kempf-netlmm-nohost-ps-00 Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOBOPTS Y. Cui 3 Internet-Draft K. Xu 4 Expires: January 12, 2006 J. Wu 5 CERNET 6 H. Deng 7 Hitachi 8 July 11, 2005 10 Handover Control Function Based Handover for Mobile IPv6 11 draft-cui-mobopts-hcf-wlan-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 12, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document propose a scheme to support MIP6 deployment based on 45 Wireless LAN by extending HMIPv6. The HCF (Handover Control 46 Function) described in this document should record all APs's MAC 47 address, backend AR's address and network prefix of those APs. All 48 MNs will periodically report all AP's MAC address and signal strength 49 information to HCF which MN can probe, then HCF should decide whether 50 or which AP MN shall associate with and notify MN about the new AP/ 51 AR's information, meanwhile, a bi-cast mechanism shall be applied to 52 further improve handover performance by reducing the packet loss 53 during handover. This mechanism can be used in the nationwide 54 university Wireless LAN based MIP6 network deployment to support VoIP 55 and Video Telephony. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Deployment Scenario of HCF Based Handover . . . . . . . . . . 5 62 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1 Mobile Node Operation . . . . . . . . . . . . . . . . . . 8 64 4.2 Handover Control Function Operation . . . . . . . . . . . 8 65 4.3 Home Agent Operation . . . . . . . . . . . . . . . . . . . 8 66 4.4 Access Router Operation . . . . . . . . . . . . . . . . . 9 67 4.5 Correspondent Node Operation . . . . . . . . . . . . . . . 9 68 5. Mobile IPv6 Extension . . . . . . . . . . . . . . . . . . . . 10 69 5.1 HCFReq message . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1.1 AP info options . . . . . . . . . . . . . . . . . . . 11 71 5.2 HCFRep message . . . . . . . . . . . . . . . . . . . . . . 11 72 5.2.1 Acess Router information option . . . . . . . . . . . 13 73 6. HCF Bicast Traffic . . . . . . . . . . . . . . . . . . . . . . 15 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9.1 Normative References . . . . . . . . . . . . . . . . . . . 18 78 9.2 Informative References . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 80 Intellectual Property and Copyright Statements . . . . . . . . 20 82 1. Introduction 84 There are many proposals trying to give the solution for Mobile IPv6 85 deployment for Wireless LAN network. Especially there are some 86 nationwide Wireless LAN network for the universities and research 87 institutes, they would like to deploy VoIP and Video Telephone based 88 on Mobile IPv6. One important issue is that they can not modify 89 current Access Routers to support Fast handover even just small part 90 of Access Routers. In order to considering VoIP and Video Telephone, 91 the performance of fast handover have to be achieved. 93 This document propose a scheme to support MIP6 deployment based on 94 Wireless LAN by extending HMIPv6. The HCF (Handover Control 95 Function) described in this document should record all APs's MAC 96 address, backend AR's address and network prefix of those APs. All 97 MNs will periodically report all AP's MAC address and signal strength 98 information to HCF which MN can probe, then HCF should decide whether 99 or which AP MN shall associate with and notify MN about the new AP/ 100 AR's information, meanwhile, a bi-cast mechanism shall be applied to 101 further improve handover performance by reducing the packet loss 102 during handover. 104 Before MN handover the new AP/AR, HCF shall notify MN about the new 105 AP/AR's information such as AP's MAC address, AR interface address, 106 and network prefix. Then, MN will configure its new CoA before 107 moving to the new AP. After handover, Layer 2 trigger may be used to 108 support the handover. This protocol defines two mobility options to 109 support communication between MN and HCF. 111 Since HCF decide which AR's interface MN will move to, so the new 112 network prefix of MN will be notified by HCF through HCFRep message. 113 If MN's address is computed using interface indentifier, like EUI64, 114 Duplicated Address Detection can be omitted during handover. 115 Furthermore, recent study reveals that DAD is not _applicable_ to 116 Wireless LAN environment. Therefore, In this protocol, HCF will know 117 MN's new CoA according to MN's old CoA and MN's new network prefix. 118 Under this situation, a bi-casting mechanism can also be applied to 119 further improve handover performance. HCF will act as a extention of 120 MAP in HMIPv6 which shall begin to bi-cast to both MN's old CoA and 121 new CoA after sending HCFRep to MN in order to reduce packet loss 122 during handover. 124 This protocol can be used in the nationwide university Wireless LAN 125 based MIP6 network deployment to support VoIP and Video Telephony. 127 2. Terminology 129 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [1]. 133 In addition, new terms are defined below:: 135 Home Agent (HA) A router on a MN's home link with which the MN has 136 registered its current Care-of address. While the MN is away from 137 home, the HA intercepts packets on the home link destined to the MN's 138 home address, encapsulates them, and tunnels them to the MN's 139 registered Care-of address. 141 Handover Control Function (HCF) 143 A extension of MAP in HMIPv6 which should record all APs's MAC 144 address, backend AR's address and network prefix of those APs. 145 HCF should decide whether or which AP MN shall associate with and 146 notify MN about the new AP/AR's information. Meanwhile, HCF shall 147 split a bi-cast stream to both MN's new CoA and old CoA. 149 Mobile Node (MN) 151 A node that can change its point of attachment from one link to 152 another, while still being reachable via its home address. 154 Access Point (AP) 156 A Layer 2 device connected to an IP subnet that offers wireless 157 connectivity to a MN. An Access Point Identifier (AP-ID) refers 158 the AP's L2 address. Sometimes, AP-ID is also referred to as a 159 Base Station Subsystem ID (BSSID). 161 Access Router (AR) 163 The MN's default router 165 Handover 167 A process of terminating existing connectivity and obtaining new 168 IP connectivity. 170 Bicasting 172 The splitting of a stream of packets destined for a MN via its 173 current HCF(the MAP) into two streams, and the simultaneous 174 transmission of thestreams to old CoA and new CoA. 176 3. Deployment Scenario of HCF Based Handover 178 The following Figure gives the topology layout about how to deploy 179 this protocol (HCF Based handover for Mobile IPv6) for nationwide 180 Mobile IPv6 network deployment based on Wireless LAN. 182 |------------------------------| |---------- 183 | | | | 184 |---| |---| |---| |---| 185 |HA | |HA | |HA | |CN | 186 |---| |---| |---| |---| 187 |-------------------------------------------------------| 188 | | 189 | Internet | 190 | | 191 |-------------------------------------------------------| 192 | | 193 |----| |----| 194 |HCF1| |HCF2| 195 |----| |----| 196 / \ / \ 197 / \ / \ 198 / \ / \ 199 / \ / \ 200 |---| |---| |---| |---| 201 |AR1| |AR2| |AR3| |AR4| 202 |---| |---| |---| |---| 203 /\ | /\ | 204 / \ | / \ | 205 / \ | / \ | 206 | | | | | | 207 |---| |---| |---| |---| |---| |---| 208 |AP1| |AP2| |AP3| |AP4| |AP5| |AP6| 209 |---| |---| |---| |---| |---| |---| 210 / \ 211 / \ 212 / \ 213 /\ /\ 214 /MN\ ------------> /MN\ 215 /----\ /----\ 217 Figure 1: Network Scenario of HCF based handover 219 In this network scenario, there might one AR will connect to multiple 220 APs, those APs might have same network prefix or different network 221 prefix. 223 When MN move from AP2 to AP3, the attached Access Router also change 224 from AR1 to AR2 as well. HCF will has administrative network domain, 225 which can cover many ARs and APs. 227 There are some network deployment scenarios such as University. 228 There are might have one or multiple HCF in one university. If there 229 are more than one HCF in each university, the inter-connection 230 between different HCF will be out of the scope of this document. 232 4. Protocol Operation 234 MN HCF HA 235 | | | 236 |------------------- BU ------------------>| 237 | | | 238 |<------------------ BA -------------------| 239 | | | 240 |------HCFReq-------->| | 241 | | | 242 |<-----HCFRep---------| | 243 | | | 244 Config New CoA | | 245 ....Handover | | 246 Layer 2 trigger | | 247 | | | 248 |------- BU --------->| | 249 |<------ BA ----------| | 250 | |------- BU -------->| 251 | |<------ BA ---------| 252 |<====================== deliver packets 253 | | 255 Figure 2: Protocol for HCF based handover 257 1. When MN register to HA first time, it will send Bingding Update 258 message to HA, and HA will response with Binding Acknowledgement. 260 2. After MN probes all Neighbor AP's information, and MinWlanTime is 261 up, MN shall send HCFReq message directly to HCF to report the 262 information of its neighbor AP. 264 3. After HCF receive the MAPReq message, it will decide whether or 265 which AR/AP MN shall associate with. 267 4. Detail algorithm for HCF judgement of MN handover mostly is based 268 on the signal strenth MN received from neighbor APs and HCF's 269 network administraing policy. 271 5. HCF judge MN in some sense which also can help load balance among 272 different ARs and APs, if the number of registered MNs in one AR 273 or AP have over more than the threshold, HCF will not approve MN 274 move to that network. 276 6. After HCF make decision which AR/AP MN will move to, HCF will 277 notify MN about new AR/AP's information such as link prefix and 278 AR's address. Those information will help MN make a new CoA 279 before it handover. This address also has been known by HCF 280 since new CoA is made based on EUI-64. 282 7. After MN receive the HCFReq message, it knows which AR/AP it will 283 associate with and will configure its new CoA based on HCFReq 284 message information about new AP/AR. 286 8. When MN moves from AP2 to AP3, the attached Access Router also 287 change from AR1 to AR2. MN will intensively deassociate with AP2 288 and associate with AP3. 290 9. HCF works as an extension of MAP, and will send bicast traffic 291 from HCF to both MN's old CoA and new CoA. Once MN attach AP3/ 292 AR2, those traffic will go directly to MN's new CoA. After 293 receving the new binding update from new CoA, HCF will remove 294 traffic going to old coA. 296 4.1 Mobile Node Operation 298 Mobile Node will periodically report all neighbor's AP information to 299 HCF by using HCFReq message, and modify its configuration based on 300 informaiton transferred by HCFRep message. And also Mobile Node 301 shall support layer 2 trigger and optimized DAD to support fast 302 handover. 304 4.2 Handover Control Function Operation 306 HCF should collect all AP's MAC address, and AR's address and network 307 prefix et al. It can be done by network administrators manualy or 308 other solution which is out the scope of this protocol. HCF create a 309 database inside or using LDAP to record those information in other 310 network entities. 312 HCF will decide whether which AP/AR MN will associate with, and will 313 notify the related information of next AR/AP to MN. 315 HCF will be responsible for authenticate and authorize the MN in 316 order to reduce signal burdern in the access network, 318 The HCF acts as a extension of MAP in hierarchical Mobile IPv6, it 319 will bicast the traffic from CN to both old CoA and new CoA. 321 4.3 Home Agent Operation 323 Home agent will work as Mobile IPv6 specificaiton, it will also 324 accept the registration from HCF as a extension of MAP in HMIPv6. 326 4.4 Access Router Operation 328 There are no specific security association requirement between MN and 329 AR, which shall save signal overhead in the access network side. 330 Meanwhile there exist some scenario, for example, in the university 331 network, access routers are not expected to do any authentication. 333 4.5 Correspondent Node Operation 335 Correspondent Node will work as Mobile IPv6 specification. 337 5. Mobile IPv6 Extension 339 MN will probe its neighor all AP's information and send these 340 information to HCF using HCFReq message. HCF will select an AP based 341 on those information together with AR's information, and respond a 342 HCFRep message including the MAC address of suggested AP along with 343 some backend AR's information in that link, like network prefix and 344 router address. 346 HCF is an indenpendent entity as MAP in HMIPv6. Messages between HCF 347 and MN are introduced above as HCFReq and HCFRep. These two messages 348 are implemented here as an extension to Mobile IPv6, the format of 349 two new Mobility Messagesare defined as following: 351 5.1 HCFReq message 353 The HCF Request message uses the MH Type value MH_HCFREQ_TYPE. When 354 this value is indicated in the MH Type field, the format of the 355 Message Data field in the Mobility Header is as follows: 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Sequence # | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Reserved | Number | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | AP info 1 | 363 . . 364 | AP info 2 | 365 . . 366 . . 367 . . 368 | AP info n | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Reserved 373 These fields are unused. They MUST be initialized to zero by the 374 sender and MUST be ignored by the receiver. 376 Sequence # 378 A 16-bit unsigned integer used by the receiving node to sequence 379 the HCFReq message and also by the sending node to match a 380 returned HCFRep message with the HCFReq. An outdated HCFRep may 381 be helpless for Mobile Node, and SHOULD be ignored by the Mobile 382 Node which sent out the HCFReq message. 384 Number 386 A 8-bit unsigned integer to indicate the number of AP info that 387 are attached below in this message. This field MUST be equal to 388 the actual number of AP info in message, otherwise HCF MUST ignore 389 this HCFReq message. The value of this field MUST be at least 1, 390 or more than one. 392 AP info 394 A HCFReq message could contain more than one AP info options. 395 Detailed description of one AP info option is defined in next 396 subsection: 398 5.1.1 AP info options 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | TBD | Strength | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 403 | MAC Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 TBD 408 TBD, consider reserved 410 Strength 412 The field is current signal strength received by Mobile Node from 413 this AP. This is a 8-bits unsigned integer which can represent 414 strength level from 0 to 255. Any special computation scheme MAY 415 be used as long as all AP are treated equally. Selection of a 416 particular computation scheme is out of scope of this draft. 418 MAC Address 420 This field is the 48-bits MAC address of the AP. Which is the 421 unique identification of AP known by Mobile Node. 423 5.2 HCFRep message 425 The HCF Reply message uses the MH Type value MH_HCFREP_TYPE. When 426 this value is indicated in the MH Type field, the format of the 427 Message Data field in the Mobility Header is as follows: 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Sequence # | Status | Number | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | AR info 1 | 435 . . 436 | AR info 2 | 437 . . 438 . . 439 . . 440 | AR info n | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Reserved 445 These fields are unused. They MUST be initialized to zero by the 446 sender and MUST be ignored by the receiver. 448 Sequence # 450 A 16-bit unsigned integer. The Sequence Number in the HCFRep is 451 copied from the Sequence Number field in the HCFReq. It is used 452 by the Mobile Node in matching this HCFRep with an outstanding 453 HCFReq message. 455 Status 457 8-bit unsigned integer indicating the disposition of the HCFReq 458 message. The following Status values are currently defined: 460 Number 462 A 8-bit unsigned integer to indicate the number of Access Router 463 info that are attached below in this message. This field MUST be 464 equal to the actual number of AR info in message, otherwise HCF 465 MUST ignore this HCFReq message. The value of this field MUST be 466 at least 1, or more than one. 468 AR info 470 A HCFRep message could contain more than one Acess Router info 471 options. Detailed description of one AP info option is define in 472 next subsection: 474 5.2.1 Acess Router information option 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | MAC Address | 478 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | | Preference | Prefix Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 + + 483 | | 484 + Prefix + 485 | | 486 + + 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 + + 491 | | 492 + Address + 493 | | 494 + + 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 MAC Address 500 This field is the 48-bits MAC address of the AP that HCF 501 suggested. 503 Preference 505 This field is a 8-bits unsigned integer indicating the preference 506 level of AP suggested by HCF. 508 Prefix Length 510 A 8-bits unsigned integer. The value of this field MUST NOT be 511 more than 128, therefore the first bit of this field MUST be 0. 512 This is prefix lenth of access router on the same link with the 513 suggested AP. 515 Prefix 517 A 128-bits IPv6 address prefix of the access router on the same 518 link with the suggested AP. 520 Address 522 A 128-bits IPv6 address of the access router on the same link with 523 the suggested AP. 525 6. HCF Bicast Traffic 527 Here HCF work as a extension of MAP in HMIPv6. After HCF send out 528 HCFRep message, it will trigger MAP to Bi-cast traffic for the MN for 529 a short period to its current location and to new location where HCF 530 suggest MN moving to shortly. 532 HCF Bicasting traffic also removes the timing ambiguity regarding 533 when to start sending traffic for the MN to its new point of 534 attachment followng a Fast Handover. It also saves the MN periods of 535 service disruption in the case of ping-pong movement. 537 Here we refer to the Bi-cast/N-cast draft [7] lifetime mechanism, the 538 HCF MUST create a new binding cache sub-entry (linked to the original 539 entry for the old CoA) for the MN's new CoA. This sub-entry contains 540 the same fields as normal binding cache entries but it MUST not 541 replace any existing entries for the MN. The new sub-entry will have 542 two lifetimes instead of one: the normal new CoA BU lifetime (sent in 543 the BA) and a Bicasting lifetime set to SHORT_BINDING_LIFETIME (sent 544 in the BA sub-option). The new CoA lifetime runs in parallel with 545 the Bicasting lifetime. Until the Bicasting lifetime expires, the 546 HCF MUST send a copy of the data destined for the MN to the old CoA 547 and to the new CoA in the linked binding cache sub-entry or sub- 548 entries. When the Bicasting lifetime expires, the HCF MUST remove 549 the bicasting lifetime field and replace the old binding cache entry 550 for the old CoA with the new CoA sub-entry. As a result, the HCF 551 will end up with one entry for the MN's new CoA with the remaining 552 new CoA lifetime. 554 The default value for SHORT_BINDING_LIFETIME is 2s. This parameter 555 MUST be configurable as it my vary depending on the type of radio 556 link in the system. 558 After HCF received BU from new CoA, old CoA binding is deleted, and 559 new CoA binding kept alive after that 561 There are also two issues similar to [7]: 1. Multiple copies of 562 packets received at AR. 2. Reception of multiple copies in the MN. 564 In this version, Multiple-Casting has not yet been considered. It 565 will be analysized in the future. 567 7. IANA Considerations 569 This document updates the IANA Registry for Mobile IPv6 Mobility 570 Header Types. 572 A new MH type MH_HCFREQ_TYPE is define in section 5.1 of this 573 document to identify new HCFReq message in Mobile IPv6 protocol. 575 A new MH type MH_HCFREP_TYPE is define in section 5.2 of this 576 document to identify new HCFRep message in Mobile IPv6 protocol. 578 8. Security Considerations 580 HCF does not introduce any more security problems than Mobile IPv6 581 and Hierarchical Mobile IPv6. Same IPSec protection used in Mobile 582 IPv6 signals MUST be used to protect two new messages, HCFReq, 583 HCFRep, in this solution. 585 All messages between MN and HCF MUST be authenticated. This means 586 that the mobile host has to share an authentication key (private or 587 public) with all HCFs it may visit. These keys can be pre-installed 588 manually or obtained dynamically via IKE or AAA servers. 590 Since HCF is an extension to Mobile Anchor Point in HMIPv6. These 591 authentication key SHOULD be the key between MN and MAP as specified 592 in HMIPv6. 594 9. References 596 9.1 Normative References 598 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 599 Levels", BCP 14, RFC 2119, March 1997. 601 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 602 Architecture", RFC 2373, July 1998. 604 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 605 IPv6", RFC 3775, June 2004. 607 9.2 Informative References 609 [4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", 610 draft-ietf-mipshop-80211fh-04 (work in progress), April 2005. 612 [5] Koodli, R., "Fast Handovers for Mobile IPv6", 613 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 614 October 2004. 616 [6] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 617 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 618 draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. 620 [7] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile IPv6 621 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05 (work in 622 progress), November 2003. 624 [8] Jung, H., "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", 625 draft-jung-mobopts-fhmipv6-00 (work in progress), April 2005. 627 [9] Kempf, J., "Problem Statement for IP Local Mobility", 628 draft-kempf-netlmm-nohost-ps-00 (work in progress), June 2005. 630 Authors' Addresses 632 Yong Cui 633 CERNET 634 Department of Computer Science and Technology 635 Tsinghua University 636 Beijing 100084 637 China 639 Email: yong@csnet1.cs.tsinghua.edu.cn 640 Ke Xu 641 CERNET 642 Department of Computer Science and Technology 643 Tsinghua University 644 Beijing 100084 645 China 647 Email: xuke@csnet1.cs.tsinghua.edu.cn 649 Jianping Wu 650 CERNET 651 Department of Computer Science and Technology 652 Tsinghua University 653 Beijing 100084 654 China 656 Email: jianping@cernet.edu.cn 658 Hui Deng 659 Hitachi 660 Beijing Fortune Bldg. 1701 661 5 Dong San Huan Bei-Lu 662 Chao Yang District 663 Beijing 100004 664 China 666 Email: hdeng@hitachi.cn 668 Intellectual Property Statement 670 The IETF takes no position regarding the validity or scope of any 671 Intellectual Property Rights or other rights that might be claimed to 672 pertain to the implementation or use of the technology described in 673 this document or the extent to which any license under such rights 674 might or might not be available; nor does it represent that it has 675 made any independent effort to identify any such rights. Information 676 on the procedures with respect to rights in RFC documents can be 677 found in BCP 78 and BCP 79. 679 Copies of IPR disclosures made to the IETF Secretariat and any 680 assurances of licenses to be made available, or the result of an 681 attempt made to obtain a general license or permission for the use of 682 such proprietary rights by implementers or users of this 683 specification can be obtained from the IETF on-line IPR repository at 684 http://www.ietf.org/ipr. 686 The IETF invites any interested party to bring to its attention any 687 copyrights, patents or patent applications, or other proprietary 688 rights that may cover technology that may be required to implement 689 this standard. Please address the information to the IETF at 690 ietf-ipr@ietf.org. 692 Disclaimer of Validity 694 This document and the information contained herein are provided on an 695 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 696 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 697 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 698 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 699 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 702 Copyright Statement 704 Copyright (C) The Internet Society (2005). This document is subject 705 to the rights, licenses and restrictions contained in BCP 78, and 706 except as set forth therein, the authors retain all their rights. 708 Acknowledgment 710 Funding for the RFC Editor function is currently provided by the 711 Internet Society.