idnits 2.17.1 draft-xia-multimob-hybrid-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. 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 IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 6, 2007) is 5988 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) -- Looks like a reference, but probably isn't: '1' on line 297 == Missing Reference: 'M' is mentioned on line 269, but not defined == Missing Reference: 'N' is mentioned on line 307, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-irtf-mobopts-mmcastv6-ps-01 == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-05 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: May 9, 2008 Huawei USA 5 November 6, 2007 7 Hybrid Subscription for Multicast Reciever Mobility in MIPv6 8 draft-xia-multimob-hybrid-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 9, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 In MIPv6 specification, there are two basic methods for mobile 42 multicast: 1) via a bi-directional tunnel from MN to its Home 43 Agent;2) via a local multicast router on the foreign link being 44 visited. In this memo, a hybrid method is introduced. MN subscribes 45 multicast service through Home agent at first. Then, MN changes its 46 subscription router to a local multicast router which can provide the 47 same multicast service. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Solution Detail . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Local Multicast Service Discovery . . . . . . . . . . . . 6 56 4.2. Multicast Group Membership Management in HA . . . . . . . 6 57 5. MLDv2 Extension . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Multicast Listener Hold-Release . . . . . . . . . . . . . 6 59 5.2. Multicast Listening State Advertisement . . . . . . . . . 7 60 5.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.2.2. Reserved and Checksum . . . . . . . . . . . . . . . . 8 62 5.2.3. Nr of Mcast Address Records (M) . . . . . . . . . . . 8 63 5.2.4. Multicast Address Record . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 9.2. Informative references . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 73 1. Introduction 75 [I-D.irtf-mobopts-mmcastv6-ps] specifies the problem scope for a 76 multicast mobility management which is further subdivided into two 77 categories: multicast listener mobility and multicast sender 78 mobility. In this memo, only the former is dealt with. 80 The problem of achieving seamless multicast listener mobility is then 81 further analyzed in three aspects: 83 1. Ensuring multicast reception even in visited networks without 84 appropriate multicast support. 86 2. Realizing native multicast forwarding whenever applicable to 87 preserve network resources and avoid data redundancy. 89 3. Expediting primary multicast forwarding at handovers. 91 Items 1 and 2 are discussed in this document, while item 3 is handled 92 in [I-D.xia-mipshop-fmip-multicast]. 94 MIPv6 [RFC3775] has specified two basic methods for mobile multicast: 95 1)via a bi-directional tunnel from MN to its HA (Home Agent), which 96 is called Home Subscription; 2) via a local multicast router on the 97 foreign link being visited, which is called Remote Subscription. In 98 Home Subscription, MN tunnels its multicast group membership control 99 packets to its HA, and the HA forwards multicast packets down the 100 tunnel to the MN . In Remote Subscription, the local multicast 101 router MUST terminate MLD messages. These two basic methods can 102 retain multicast communications when MN moves, but some issues still 103 exist. 105 o Home Subscription suffers from triangle route which is composed of 106 MN- HA tunnel and HA-S (multicast source server) multicast tree 107 path. When the MN is far from its HA, the data forwarding path of 108 multicast becomes sub-optimal. 110 o Although the multicast path in Remote Subscription is optimal, 111 frequent handoffs of MN among subnets will produce much latency. 112 Because when MN handovers, it will leave and re-join multicast 113 groups frequently. 115 As to unicast traffic, there are two possible modes in [RFC3775] for 116 communication between the mobile node and a correspondent node, that 117 is, bi-directional tunneling and route optimization. The former 118 provides basic IP connectivity while MN is moving, while the latter 119 provides efficient communication. In optimization mode, routing 120 packets directly to the mobile node's care-of address allows the 121 shortest communications path to be used. It also eliminates 122 congestion at the mobile node's home agent and home link. 124 Borrowing some ideas from unicast traffic optimization, this document 125 proposes an optimized solution for a multicast listener. 126 Subscription from home network provides basic multicast service 127 availability, while subscription from visited network provides 128 optimal multicast traffic delivery. The combination of two methods 129 is a comprehensive solution which is preliminarily referred to in 130 [Progress and Challenges]. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 The terminology in this document is based on the definitions in 139 [RFC3775], in addition to the ones specified in this section. 141 Multicast Services Capability: multicast traffic forwarding 142 capability of a multicast router. Different multicast routers 143 probably have different capability because of different local 144 policy, router processing capability and so on. In this memo, MN 145 can receive multicast traffic from HA or local AR. These two 146 entities probably have different capability to provide multicast 147 service because of different administrative domain, different 148 processing capability and so on. 150 3. Solution Overview 152 The Home Subscription or bi-directional tunneling relies on Mobile 153 IPv6 architectural entities ( HA and MN ) and uses a multicast router 154 (which is probably collocated with HA or not) on the home network. 155 If the multicast router is physically separated from HA, the HA 156 operates as a MLD proxy [RFC4605]. For simplification, this memo 157 only considers the situation that HA acts as a multicast router. 158 This simplification does not affect the operation defined in the 159 document. 161 To join a multicast group, MN establishes a bi-directional tunnel 162 with its HA and tunnels its membership report message to the HA. 163 This is encapsulated within the same tunnel header used for routing 164 unicast packets between MN and HA. HA intercepts the membership 165 message and sends a join message to an upstream router using 166 multicast control protocols (e.g. [RFC4601]). Once the multicast 167 branch is established, the HA forwards the incoming multicast packets 168 down the tunnel to the MN. 170 When the mobile receiver moves to a new foreign network, it does not 171 need to re-join the multicast group since the HA is already informed 172 about its membership. This approach suffers from triangular routing 173 across the home network, which may increase join latency. Moreover, 174 tunnel via HA incurs overhead at the home network. 176 With the Remote Subscription approach, MN joins a multicast group 177 through a local multicast router on a foreign network. To join a 178 multicast group, MN sends its membership report to the local 179 multicast router (i.e. Access Router) located on the visited 180 network. The local multicast router intercepts this membership 181 report message and joins the requested multicast group. After 182 handover to a new network, MN sends a new membership report message 183 to a new Access Router acting as a multicast router. The main 184 problem with the Remote Subscription is that the multicast services 185 capability provided by HA is probably different from AR. That is, HA 186 can join some multicast group while AR can not. 188 Multicasting according to current standards (e.g. MLDv2 [RFC3810]) 189 has drawbacks compared to unicasting when one applies it to 190 commercial services. Accounting of each user's actions is not 191 possible with multicasting as it is with unicasting. 192 [I-D.ietf-mboned-maccnt-req] proposes requirements for AAA in well 193 managed IP multicasting services. In MIPv6 scenario, HA is a default 194 multicast service provider for MN. If MN wants to subscribe 195 multicast service directly from AR, some AAA operation may be 196 performed. So, when MN in a foreign link wants to subscribe to a 197 multicast group, it sends its membership report to HA by default. 198 While MN receives multicast traffic from HA, MN initiates a Remote 199 Subscription by sending membership report. After successful Remote 200 Subscription, MN notifies HA to stop delivery of corresponding 201 multicast traffic, but hold the multicast membership in HA, as will 202 be described further in the later. 204 During handover, there is a multicast service negotiation between 205 Previous Access Router(PAR) and New Access Router (NAR). That is, 206 PAR presents MN's multicast services to NAR, and NAR replies with 207 supported multicast services based on its local policy. If the 208 multicast services (multicast group) are not supported by NAR, MN 209 then reverts to Home Subscription . 211 4. Solution Detail 212 4.1. Local Multicast Service Discovery 214 When MN wants to switch from Home Subscription to Remote 215 Subscription, MN should learn the multicast service capability 216 provided by local multicast routers. To do so, MN presents its 217 existing multicast services to AR, and AR acknowledges the multicast 218 services which can be provided locally. 220 MN sends its existing multicast services to AR through State Change 221 Report [RFC3810] once the IP connectivity with AR is established. AR 222 sends a Multicast Listening State Advertisement which is detailed in 223 Section 5.2. In this message, AR tells MN which multicast services 224 can be provided locally, so MN switches corresponding Home 225 Subscriptions to Remote Subscriptions. 227 4.2. Multicast Group Membership Management in HA 229 When MN use Remote Subscription, HA MAY terminate its packet 230 forwarding to the MN. However, to preserve its ability to restart 231 fast packet forwarding, it may be desirable for HA to remain part of 232 the multicast delivery tree. The Home Subscription is kept active by 233 a new membership message called Multicast Listener Hold defined in 234 Section 5.1 sent by MN to its HA. When MN performs Remote 235 Subscription, it sends Multicast Listener Hold message to HA for 236 stopping corresponding multicast traffic forwarding while keeping the 237 multicast membership. When MN reverts from Remote Subscription to 238 Home Subscription, it sends a message to restart the multicast 239 traffic forwarding quickly. 241 When MN wishes to leave a multicast group and sends Multicast 242 Listener Report to HA, a specific query is supposed to be sent by HA 243 to check if other listeners for the same group are present on the 244 link. But because the tunnel is per MN, HA should not send the 245 specific query message to relieve traffic. 247 5. MLDv2 Extension 249 5.1. Multicast Listener Hold-Release 251 This message is to notify a multicast router (e.g. HA) to stop 252 forwarding multicast data for the groups specified, but still 253 maintain the multicast membership on that interface. The message has 254 twofold functions: stopping forwarding a multicast traffic and 255 resuming forwarding. The following figure is Multicast Listener 256 Report format defined in [RFC3810]. Based on this, a code field is 257 designed for Multicast Listener Hold-Release message. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type = 143 | Code | Checksum | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Reserved |Nr of Mcast Address Records (M)| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Multicast Address Record [1] | 267 . . 268 . ... . 269 | Multicast Address Record [M] | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type and other fields are defined in [RFC3810]. 274 An 8-bit Code field is defined. Code value 276 1 is used to activate forwarding multicast traffic specified in the 277 message, 279 2 is used to stop forwarding while hold the membership of the 280 specified multicast address records. 282 5.2. Multicast Listening State Advertisement 284 Multicast Listening State Advertisement is sent by multicast routers 285 to advertise available multicast services for MN. The format of the 286 message is similar to Multicast Listener Report Message in [RFC3810]. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type = 143 | Reserved | Checksum | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Reserved |Nr of Mcast Address Records (M)| 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 . . 297 . Multicast Address Record [1] . 298 . . 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | . | 302 . . . 303 | . | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 . . 307 . Multicast Address Record [N] . 308 . . 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 5.2.1. Type 314 A new message type is defined , and the value SHOULD be allocated by 315 IANA. 317 5.2.2. Reserved and Checksum 319 These fields have the same meaning as the fields define in Multicast 320 Listener Report Message [RFC3810]. 322 5.2.3. Nr of Mcast Address Records (M) 324 The Nr of Mcast Address Records (M) field specifies how many 325 Multicast Address Records are present in this Report. 327 5.2.4. Multicast Address Record 329 Each Multicast Address Record is a block of fields that contain 330 multicast groups information that MN can subscribe on the link from 331 which the advertisement is sent. 333 6. Security Considerations 335 Home Subscription shares bi-directional tunnel which is built for 336 unicast traffic. HA and MN has a security association to protect the 337 tunnel. As for Remote Subscription, there is no addition threats 338 introduced comparing with MLDv2 [RFC3810]. 340 7. IANA consideration 342 8. Acknowledgements 344 9. References 346 9.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 352 in IPv6", RFC 3775, June 2004. 354 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 355 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 357 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 358 "Internet Group Management Protocol (IGMP) / Multicast 359 Listener Discovery (MLD)-Based Multicast Forwarding 360 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 362 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 363 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 364 Protocol Specification (Revised)", RFC 4601, August 2006. 366 9.2. Informative references 368 [Progress and Challenges] 369 Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP 370 Networks: Progress and Challenges", IEEE Wireless Comm., 371 2002. 373 [I-D.irtf-mobopts-mmcastv6-ps] 374 Schmidt, T. and M. Waehlisch, "Multicast Mobility in 375 MIPv6: Problem Statement and Brief Survey", 376 draft-irtf-mobopts-mmcastv6-ps-01 (work in progress), 377 July 2007. 379 [I-D.xia-mipshop-fmip-multicast] 380 Xia, F. and B. Sarikaya, "FMIPv6 extension for Multicast 381 Handover", draft-xia-mipshop-fmip-multicast-01 (work in 382 progress), March 2007. 384 [I-D.ietf-mboned-maccnt-req] 385 He, H., "Requirements for Multicast AAA coordinated 386 between Content Provider(s) and Network Service 387 Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in 388 progress), October 2007. 390 Authors' Addresses 392 Frank Xia 393 Huawei USA 394 1700 Alma Dr. Suite 100 395 Plano, TX 75075 397 Phone: +1 972-509-5599 398 Email: xiayangsong@huawei.com 400 Behcet Sarikaya 401 Huawei USA 402 1700 Alma Dr. Suite 100 403 Plano, TX 75075 405 Phone: +1 972-509-5599 406 Email: sarikaya@ieee.org 408 Full Copyright Statement 410 Copyright (C) The IETF Trust (2007). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 420 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 421 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; nor does it represent that it has 431 made any independent effort to identify any such rights. Information 432 on the procedures with respect to rights in RFC documents can be 433 found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use of 438 such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository at 440 http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights that may cover technology that may be required to implement 445 this standard. Please address the information to the IETF at 446 ietf-ipr@ietf.org. 448 Acknowledgment 450 Funding for the RFC Editor function is provided by the IETF 451 Administrative Support Activity (IASA).