idnits 2.17.1 draft-suh-mipshop-fmcast-mip6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 35 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 298: '... bit SHOULD be set to 1. With the i...' RFC 2119 keyword, line 307: '... SHOULD send the HI message to the ...' RFC 2119 keyword, line 313: '...cast Service, it SHOULD send the HAck ...' RFC 2119 keyword, line 433: '... PrRtAdv message MAY have options. The...' RFC 2119 keyword, line 477: '...N currently subscribes to. MAY be more...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7407 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: '3' is defined on line 550, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 552, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-fast-mipv6-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-fast-mipv6 (ref. '1') ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF MIPSHOP Working Group Kyungjoo Suh 2 Internet Draft Samsung Electronics 3 Dong-Hee Kwon 4 Young-Joo Suh 5 POSTECH 6 Youngjun Park 7 Samsung Electronics 9 Document: draft-suh-mipshop-fmcast-mip6-00.txt 10 Expires: July 2004 January 2004 12 Fast Multicast Protocol for Mobile IPv6 13 in the fast handovers environments 15 Status of This Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-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 25 any 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 Abstract 36 This document defines the Fast Multicast Protocol for Mobile IPv6 37 [2] in the Fast Handovers environments whereby a mobile node (MN) 38 can receive multicast data with reduced loss and delay after 39 handoffs. The proposed protocol can be implemented by the simple 40 modification of the Fast Handovers protocol [1] so that it can be 41 easily applied to the Fast Handovers for Mobile IPv6. This document 42 does not need a certain assumption of a specific multicast routing 43 protocol, so that any existing multicast routing protocol can be 44 used with the proposed protocol. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview of Fast Multicast protocol . . . . . . . . . . . . . . . 4 54 4. Fast Multicast Protocol Operation . . . . . . . . . . . . . . . . 5 56 4.1 Fast Multicast in Predictive Fast Handovers environment . . . 7 58 4.2 Fast Multicast in Reactive Fast Handovers environment . . . . 8 60 4.3 Message Format in Fast Multicast protocol . . . . . . . . . 9 62 4.3.1 Modified PrRtAdv Message Format . . . . . . . . . . . . 9 64 4.3.2 MH Multicast Address Option Format . . . . . . . . . . 10 66 4.3.3 ICMP Multicast Address Option Format . . . . . . . . . 11 68 5. Security Consideration . . . . . . . . . . . . . . . . . . . . . . 12 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Mobile IP has been proposed to provide a seamless connection when 78 a MN changes the point of attachment to the network. In general, 79 in the basic Mobile IPv6 [2], the multicast data delivery schemes 80 are defined in addition to the unicast data delivery. In the Mobile 81 IP, some packets for the MN may be lost when a MN handoffs between 82 two access routers. Although the Fast Handovers protocol [1] is 83 proposed to reduce such loss and delay, it focuses on the unicast 84 data delivery. This means the Fast Handovers protocol cannot 85 reduce the multicast data loss and delay during MN's handoffs. 87 If a MN wants to receive a multicast data, it should subscribe to 88 a corresponding multicast group. When a MN handoffs to a new 89 network that does not subscribe to a multicast group in which a MN 90 interests, it should initiate a procedure to subscribe to a 91 multicast group after finishing a handoff procedure. The fact 92 causes a multicast data loss and delay. 94 This document describes a Fast Multicast protocol to reduce a 95 multicast data loss and delay. In the proposed protocol, a MN sends 96 the information about a multicast group to which MN subscribes, to 97 the current access router before a MN handoffs to another network. 98 After receiving this information, the current access router sends 99 this information to the nearby access router to which the MN will 100 handoff in order to subscribe to a multicast group. When the MN 101 handoffs to another network, the access router of the network can 102 deliver multicast data packets to the MN, because it already 103 subscribes to a multicast group. Therefore the MN can receive 104 multicast data with reduced loss and delay after handoffs. The 105 proposed protocol can be implemented by the simple modification of 106 Fast Handovers protocol [1] so that it can be easily applied to Fast 107 Handovers protocol for Mobile IPv6. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as describe in RFC 2119. 115 In this document, some terminologies are same as defined in the 116 Fast Handovers protocol [1] such as MN, AR, NAR, PAR, RtSolPr, 117 PrRtAdv, HI, Hack, FBU, FBack, FNA, etc. The following terminologies 118 are used in this document. 120 Multicast Service 122 One to many communication service by which a node joining in a 123 specific multicast group can receive data from a multicast 124 sender. 126 Multicast Latency 128 The time difference between when a MN is last able to send 129 and/or receive a multicast data packet by way of the PAR, and 130 when the MN is able to send and/or receive a multicast data 131 packet through the NAR. 133 3. Overview of Fast Multicast protocol 135 Fast Multicast protocol presents MNs with a fast and seamless 136 multicast data delivery by exchanging information related to a 137 multicast group between ARs (PAR and NAR). By Fast Multicast 138 operations, a NAR can learn, in advance, the information on a 139 multicast group in which the MN interests. The main goal of the 140 Fast Multicast is minimizing the Multicast Latency that is 141 required when a MN moves from one AR to another while receiving 142 a Multicast Service. The Fast Multicast can be applied to the Fast 143 Handovers protocol with slight modification. Furthermore, the Fast 144 Multicast is independent of multicast routing protocols. 146 If a MN wants to receive a Multicast Service continuously after 147 handoffs to a network managed by NAR, the Fast Multicast protocol 148 lets a NAR subscribe to a multicast group, in advance, before the 149 MN handoffs to its network. During a Fast Handovers protocol 150 process, MN sends a FBU message to a PAR with new multicast address 151 option. The new multicast address option contains a multicast 152 address(es) which a MN subscribes to and wants to receive a 153 multicast service after handoffs to a NAR network. After receiving 154 a FBU message, a PAR exchanges HI/Hack messages between a NAR and 155 itself. A PAR sends multicast address option when it sends a HI 156 message to a NAR. A NAR subscribes to a multicast group contained 157 in the multicast address option when receiving a HI message. If a 158 NAR refuses to subscribe to a multicast group, it sends that 159 information to a PAR with HAck message and a PAR to a MN with FBack 160 message. Through this procedure, a MN can receive a multicast data 161 from the NAR when it completes a Fast Handovers procedure. 163 If there are some multicast groups that a NAR refuses to subscribe 164 to, a MN receives a multicast data from a PAR using established 165 tunnel between a PAR and a NAR. When a multicast receiver is a MN 166 which handoffs to a neighbor network, a PAR forwards a MLD Query 167 message to the MN using tunnel between a PAR and a NAR. If the MN 168 replies to the MLD Query message with a MLD Report message, a PAR 169 forwards a multicast data packet to the MN. Therefore the MN can 170 receive a multicast data packet. 172 4. Fast Multicast Protocol Operation 174 Figure 1 and Figure 2 show a Fast Multicast protocol operation in 175 a Predictive and Reactive Fast Handovers environment. 177 In the Fast Multicast protocol, one new flag and two new options 178 are defined as followings: 180 Multicast Service (M) bit 181 It indicates whether the AR which a MN requests a L3 information 182 in a RtSolPr message supports a multicast service or not. 184 Mobility Header Multicast Address Option 185 It is a new mobility header option which contains a multicast 186 address(es) that a MN subscribes to. It is refered as MH 187 Multicast Address Option in this document. The format of this 188 option is defined in section 4.3. 190 ICMPv6 Multicast Address Option 191 It is a new ICMPv6 option which contains a similar information 192 of a Mobility Header Multicast Address Option. The proposed 193 protocol also defines a new ICMPv6 option that has similar 194 information because HI and HAck messages of a Fast Handovers 195 protocol are delivered using ICMPv6. It is refered as ICMP 196 Multicast Address Option in this document. The format of this 197 option is defined in section 4.3. 199 In a Predictive Fast Handovers protocol, when the PAR receives a FBU 200 message, it knows that the MN handoffs soon and informs the NAR of 201 this information through the exchange of HI and HAck messages. The 202 PAR includes ICMP Multicast Address Option in the HI message to 203 transmit a multicast address(es) if a MN wants to receive a 204 Multicast Service in a network managed by NAR. The NAR receiving HI 205 message transmits HAck message with an ICMP Multicast Address Option 206 which informs whether it supports requested Multicast Service or not. 207 If the NAR accepts a request, it joins a multicast group(s). The PAR 208 receiving HAck message copies the multicast address(es) in the ICMP 209 Multicast Address Option to the MH Multicast Address Option in the 210 FBack message, and sends the message to the MN to inform the MN of 211 success or failure of the Multicast Service request. Therefore, 212 the MN knows success or failure of Multicast Service request when 213 receives the FBack message. If Multicast Service request succeeds, 214 the MN informs the NAR of its arriving after handoffs by sending 215 FNA message with MH Multicast Address Option. The MH Multicast 216 Address Option in the FNA message requests the NAR to forward the 217 multicast data to the MN. 219 In a Reactive Fast Handovers protocol, the MN does not receive FBack 220 message on the PAR network. The MN sends FNA message as soon as it 221 attaches to the NAR with FBU message. In order to enable the NAR to 222 MN PAR NAR 223 | | | 224 |--------RtSolPr---------->| | 225 |<----- PrRtAdv(M bit) ----| | 226 | | | 227 |-----------FBU----------->|----------HI------------>| 228 | (MH Multicast Option) | (ICMP Multicast Option) | 229 | | Join to 230 | | Multicast 231 | | Group 232 | |<--------HAck------------| 233 | | (ICMP Multicast Option) | 234 | | | 235 | <----FBack-----|----FBack-----> | 236 | (MH Multicast Option) | (MH Multicast Option) | 237 | | | 238 disconnect forward | 239 | packets====================>| 240 | | | 241 | | | 242 connect | | 243 | | | 244 |------------- FNA (MH Multicast Option) ----------->| 245 |<=============================================== deliver 246 | | packets 247 | | | 249 Figure 1: Fast Multicast in Predictive Fast Handover 251 MN PAR NAR 252 | | | 253 |--------RtSolPr---------->| | 254 |<----- PrRtAdv(M bit) ----| | 255 | | | 256 disconnect | | 257 | | | 258 connect | | 259 | | | 260 |-------- FNA[FBU(MH Multicast Option)] ------------>| 261 | | Join to 262 | | Multicast 263 | | Group 264 | |<-------- FBU -----------| 265 | | | 266 | |-------- FBack --------->| 267 | | | 268 | forward | 269 | packets====================>| 270 | | | 271 |<=============================================== deliver 272 | | packets 273 | | | 275 Figure 2: Fast Multicast in Reactive Fast Handover 277 forward packets immediately (when FBU message has been processed), 278 the MN encapsulates FBU message in FNA message. The exchange 279 procedure of the FBU and FBack message between PAR and NAR is 280 defined in the Fast Handovers protocol. The NAR subscribes to a 281 multicast group using the multicast address informed by the MH 282 Multicast Address Option. Except this, other operations are same 283 as defined in the Fast Multicast protocol when the Predictive Fast 284 Handovers Protoocl is used. 286 4.1 Fast Multicast in Predictive Fast Handovers environment 288 All description of this section makes use of Figure 1 as the 289 reference. 291 When a MN determines to handoff soon, it sends a RtSolPr message 292 to a PAR as defined in the Fast Handovers protocol. In response, 293 the PAR sends a PrRtAdv message including M bit that represents 294 whether the corresponding NAR supports a Multicast Service or not. 295 The method by which Access Routers exchange information about the 296 Multicast Service support of their neighbors is outside the scope 297 of this document. If the NAR supports a Multicast Service, this 298 bit SHOULD be set to 1. With the information provided in the 299 PrRtAdv message, the MN knows whether the NAR can support a 300 Multicast Service or not. If the MN does not interest in a 301 Multicast Service, it silently ignores the M bit. After then the 302 MN sends a FBU message including a MH Multicast Address Option. 303 The purpose of MH Multicast Address Option is to inform the PAR 304 of the multicast address(es) which a MN subscribes to. 306 The PAR receiving a FBU message with a MH Multicast Address Option 307 SHOULD send the HI message to the NAR with an ICMP Multicast 308 Address Option which is derived from the MH Multicast Address Option 309 of the FBU message. Through ICMP Multicast Address Option in a HI 310 message, the NAR knows that the MN wants to receive a Multicast 311 Service after handoffs. Therefore the NAR checks whether it can 312 support Multicast Service or not. If the NAR cannot support a 313 requested Multicast Service, it SHOULD send the HAck message to the 314 PAR with an ICMP Multicast Address Option. The purpose of this ICMP 315 Multicast Address Option is to inform the MN of the multicast 316 address(es) that the NAR cannot subscribe to. When the NAR can 317 support of some of multicast Services, only address(es) that the 318 NAR refused to subscribe is included in the ICMP Multicast Address 319 Option. Therefore there is no ICMP Multicast Address Option if the 320 NAR can support all of the Multicast Service requested in 321 the ICMP Multicast Address Option of a HI message. 323 The NAR also joins the multicast group to which it subscribe for 324 supporting MN. The method by which the NAR joins to a multicast 325 group is outside the scope of this document. After the PAR receives 326 a Hack Message from the NAR, it sends a FBack message to the MN. 327 This message also includes the MH Multicast Adddress Option derived 328 from the ICMP Multicast Address Option of the HACK message. The 329 purpose the MH Multicast Address Option is the same as the ICMP 330 Multicast Address Option of the Hack Message. 332 If the MN receives FBack message without MH Multicast Address Option 333 the NAR can support all of the Multicast Service requested by the MN. 334 In that case, the MN sends a FNA message with MH Multicast Address 335 Option which the MN wants to subscribes to after complete the 336 handover procedure. Through the multicast address(es) of this 337 option, the NAR can send multicast data to the MN. 339 If the NAR refuses the MN's request, the MN cannot receive a 340 Multicast Service at the NAR's network after handoffs. In this 341 case, some other methods are required to support seamless Multicast 342 Service. In the proposed protocol, the PAR forwards a multicast 343 data to the MN using tunnel between the PCoA and the NCoA. The ICMP 344 MLD protocol is assumed to manage multicast group members in the 345 proposed protocol. 347 The PAR sends periodically an ICMP MLD Query message to its network. 348 If a multicast receiver exists in a different network, the PAR 349 forwards an ICMP MLD Query message to a remote multicast receiver 350 (e.g. MN) when the tunnel exits. In the proposed protocol, the 351 tunnel is created between a PCoA and a NCoA as defined in the Fast 352 Handovers protocol. When the MN receives a MLD Query message from 353 the PAR through a tunnel, it sends a MLD Report message in response 354 to a MLD Query message if it wants to receive a Multicast Service 355 from the PAR. 357 When the PAR receives multicast data, it checks whether the tunnel 358 exists between the PCoA and the NCoA, and then checks whether it 359 should forward the multicast data through the tunnel or not. The PAR 360 forwards a multicast data through the tunnel when the tunnel exists 361 and there is a multicast receiver. Based on these procedures, the MN 362 can receive seamless Multicast Service within the network where the 363 Multicast Service is not supported. 365 This method can be also applied to a case in which the NAR accepts 366 a Multicast Service but the join procedure has not been finished yet 367 after MN's handover. In this case, the MN replies to the MLD Query 368 Message from the PAR by the MLD Report message to maintain tunnel 369 until the join procedure is finished. Therefore the MN can receive 370 multicast data from the PAR. When the join procedure is finished, 371 the NAR starts to send the MLD Qurey message and the MN sends a MLD 372 Report message in response. As the MN replies to the MLD Query 373 message from the PAR by the MLD Done message, the PAR does not 374 forward the multicast data to the MN any more. 376 4.2 Fast Multicast in Reactive Fast Handover environment 378 All description of this section makes use of Figures 2 as a 379 reference. 381 In the Reactive Fast Handover protocol, the MN does not receive a 382 FBack message at the PAR's network. Therefore the MN should send 383 immediately a FNA with FBU message when it detects an attachment to 384 a NAR's network. The MN also sends a MH Multicast Address Option in 385 the FBU message. When the NAR receives a FNA with FBU message from 386 a MN, it sends a FBU message included in the FNA message to the PAR. 387 Before the NAR sends a FBU message to the PAR, it joins to a 388 multicast group(s) which a MN requests to subscribe to. The PAR 389 sends a FBack message to the NAR in response to the FBU message. 390 In addition, the PAR forwards a MLD Query message to the MN. Through 391 this procedure, the MN can receive a Multicast Service at the NAR 392 network when the Reactive Fast Handovers protocol is used. 394 4.3 Message Formats in Fast Multicast protocol 396 Basic message formats of the proposed Fast Multicast Protocol are 397 the same as defined in the Fast Handovers protocol. Only the PrRtAdv 398 message is slightly modified. The proposed protocol also defines 399 new MH Multicast Option and ICMP Multicast Option. 401 4.3.1 Modified PrRtAdv Message Format 403 The Proposed protocol modifies the format of PrRtAdv message by 404 adding a single flag bit in the Reserved field to indicate whether the 405 neighbor AR which a MN request in RtSolPr message 406 supports multicast service or not. When the MN does not interest 407 in a multicast service, it silently ignores this bit. The format of 408 the PrRtAdv Message is as follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Code | Checksum | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Identifier |M| Reserved | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Options ... 418 +-+-+-+-+-+-+-+-+-+-+-+- 420 This format represents the following changes over that originally 421 specified in the Fast Handovers protocol[1]: 423 Multicast Service (M) 425 The Multicast Service (M) bit is set in PrRtAdv message to indicate 426 that the AR which MN requests in RtSolPr message also supports 427 multicast service 428 Reserved 430 Reduced from a 16-bits field to a 15-bits field on account of 431 the addition of the above bit 433 The PrRtAdv message MAY have options. These options MUST use the 434 Option format defined in Fast Handovers [1]. 436 4.3.2 MH Multicast Address Option Format 438 The proposed protocol defines a new mobility option, Multicast 439 Address option, that can be used in a FBU and FNA messages to 440 indicate the multicast address(es) which a MN wishes to subscribe 441 to. The format of the MH Multicast Address option is as follows: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type | Length | Number | Reserved | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 + + 450 | | 451 + Multicast Address + 452 | | 453 + + 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Type 459 TBA 461 Length 463 8-bit unsigned integer, representing the length in octets of the 464 mobility options, not including the Type and Length field 466 Number 468 Number of the multicast address which presents in Multicast 469 Address field. 471 Reserved 473 Must be set to zero by the sender and ignored by the receiver. 475 Multicast Address 477 Multicast address which a MN currently subscribes to. MAY be more 478 than one because MN can subscribe to several multicast addresses. 480 4.3.3 ICMP Multicast Address Option Format 482 The proposed protocol defines a new ICMPv6 option, Multicast Address 483 option, used in a HI and HAck messages. In the HI messages, this 484 option notifies a NAR of the multicast address(es) which a MN 485 continuously wants to subscribe to after connected to NAR's network. 487 In the HAck message, this option notifies a PAR, a NAR through a 488 FBack message, of the multicast address(es) which a NAR cannot 489 support. The format of the ICMP Multicast Address option is as 490 follows: 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Length | Sub-Type | Number | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 + + 499 | | 500 + Multicast Address + 501 | | 502 + + 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Type 508 TBA 510 Length 512 8-bit unsigned integer, representing the length in octets of the 513 mobility options, not including the Type and Length field 515 Sub-Type 517 0 519 Number 521 Number of the multicast address which presents in Multicast 522 Address field. 524 Multicast Address 526 Multicast address which is copied from Fast Binding Update. MAY 527 be more than one because MN can send Fast Binding Update to PAR 528 with several multicast addresses. 530 5. Security Considerations 532 The security considerations resulting from the use of this framework 533 do not offer any higher level of security in basic mobile IP 534 operation. Therefore, in the next version of this document will 535 include an appropriate level of security for Fast Multicast protocol. 537 Acknowledgements 539 The authors would like to acknowledge the contribution from Woo-Jae Kim 540 to improve this specification. 542 References 544 [1] Rajeev Koodli, "Fast Handovers for Mobile IPv6", Internet Draft, 545 draft-ietf-mipshop-fast-mipv6-00.txt, October 2003 547 [2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 548 draft-ietf-mobileip-ipv6-24.txt, June 2003 550 [3] C.perkins, "IP Mobility Support for IPv4", RFC3344, August 2002 552 [4] S. Deering, W. Fenner and B. Haberman, "Multicast Listener 553 Discovery (MLD) for IPv6", RFC 2710, October 1999 555 Author's Address 557 Questions about this memo can be directed to: 559 Kyungjoo Suh (Joo Suh) 560 Global Standards and Strategy team 561 Telecommunication R & D Center 562 Samsung Electronics Co., LTD. 563 Dong Suwon P.O. BOX 105, 564 416, Maetan-3dong, Youngtong-gu, 565 Suwon-city, Gyeonggi-do, 442-600 566 Korea 567 Phone: +82-31-279-5123 568 Email: joo.suh@samsung.com 569 Fax: +82-31-279-5130 571 Dong-Hee Kwon 572 POSTECH 573 Dept. of Computer Science and Engineering 574 Pohang, KOREA 575 Phone: +82-54-279-5671 576 E-Mail: ddal@postech.edu 577 Fax: +82-54-279-5699 578 Young-Joo Suh 579 POSTECH 580 Dept. of Computer Science and Engineering 581 Pohang, KOREA 582 Phone: +82-54-279-2243 583 E-Mail: yjsuh@postech.edu 584 Fax: +82-54-279-5699 586 Youngjun Park 587 Global Standards and Strategy team 588 Telecommunication R & D Center 589 Samsung Electronics Co., LTD. 590 Dong Suwon P.O. BOX 105, 591 416, Maetan-3dong, Youngtong-gu, 592 Suwon-city, Gyeonggi-do, 442-600 593 Korea 594 Phone: +82-31-279-5979 595 Email: youngjun74.park@samsung.com 596 Fax: +82-31-279-5130