idnits 2.17.1 draft-zuniga-multimob-smspmip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3376], [RFC5213], [RFC3810]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 14, 2010) is 5209 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) == Missing Reference: 'RFC-2119' is mentioned on line 105, but not defined == Unused Reference: 'RFC2119' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.deng-multimob-pmip6-requirement' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'I-D.schmidt-multimob-pmipv6-mcast-deployment-03' is defined on line 458, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- No information found for draft-deng-multimob-pmip6-requirements - is the name correct? == Outdated reference: A later version (-04) exists of draft-schmidt-multimob-pmipv6-mcast-deployment-03 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MULTIMOB Group JC.Zuniga 2 Internet Draft G.Lu 3 Intended status: Standards Track A.Rahman 4 Expires: July 14, 2010 InterDigital Communications, LLC 5 January 14, 2010 7 Support Multicast Services Using Proxy Mobile IPv6 8 draft-zuniga-multimob-smspmip-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on July 14,2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes how multicast mobility services can be 47 supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener 48 Discovery (MLD) [RFC3810], and Internet Group Management Protocol 49 (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for 50 multicast listener mobility. It proposes the use of a dedicated Local 51 Mobility Anchor as the topological anchor point for multicast 52 traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy. 53 There are no impacts to the Mobile Node to support multicast listener 54 mobility. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions and Terminology....................................3 60 3. Solution.......................................................3 61 3.1. Architecture..............................................3 62 3.2. Multicast Establishment...................................5 63 3.3. Multicast Mobility........................................6 64 3.4. Advantages................................................7 65 4. Security Considerations.......................................11 66 5. IANA Considerations...........................................11 67 6. References....................................................11 68 6.1. Normative References.....................................11 69 6.2. Informative References...................................12 70 7. Acknowledgments...............................................12 72 1. Introduction 74 Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving 75 the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the 76 Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the 77 network and does the mobility management on behalf of the Mobile Node 78 (MN). The Local Mobility Anchor (LMA) is the home agent for the MN 79 and the topological anchor point. PMIPv6 was originally designed for 80 unicast traffic. 82 The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by 83 IPv4 hosts to report their IP multicast group memberships to 84 neighboring multicast routers. Multicast Listener Discovery (MLDv2) 85 [RFC3810] is used in a similar way by IPv6 routers to discover the 86 presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4605] 87 allows an intermediate (edge) node to appear as a multicast router to 88 downstream hosts, and as a host to upstream multicast routers. IGMP 89 and MLD related protocols were not originally designed to address IP 90 mobility of multicast listeners (i.e. IGMP and MLD protocols were 91 originally designed for fixed networks). 93 Supporting mobility of multicast traffic has been under discussions 94 within the MULTIMOB working group. This document focuses on 95 addressing multicast listener mobility using the PMIPv6 and IGMP/MLD 96 protocols. It proposes the use of a dedicated LMA as the topological 97 mobility anchor point for multicast traffic, while the MAG serves as 98 an IGMP/MLD proxy. 100 2. Conventions and Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC-2119]. 106 This document uses the terminology defined in [RFC5213], [RFC3775], 107 and [RFC3810]. 109 3. Solution 111 A PMIPv6 domain may receive data from both unicast and multicast 112 sources. A dedicated LMA can be used to serve as the mobility anchor 113 for multicast traffic. Unicast traffic will go normally to the other 114 LMAs in the PMIPv6 domain. This section describes how the multicast 115 LMA works in scenarios of mobile node attachment and multicast 116 mobility. 118 3.1. Architecture 120 Figure 1 shows an example of a PMIPv6 domain supporting multicast 121 mobility. LMA1 is dedicated to unicast traffic, and LMA2 is dedicated 122 to multicast traffic. Note that there can multiple LMAs dedicated to 123 unicast traffic (not shown in Figure 1) in a given PMIPv6 domain. 124 However, we assume a single LMA dedicated to multicast traffic in a 125 PMIPv6 domain (as shown in Figure 1). 127 Also in this architecture, all MAGs that are connected to the 128 multicast LMA must support the MLD proxy [RFC4605] function. 129 Specifically in Figure 1, each of the MAG1-LMA2 and MAG2-LMA2 tunnel 130 interface defines an MLD proxy domain. The MNs are considered to be 131 on the downstream interface of the MLD proxy (in the MAG), and LMA2 132 is considered to be on the upstream interface (of the MAG) as per 133 [RFC4605]. Note that MAG could also be an IGMP proxy. For brevity 134 this document will refer primarily to MLD proxy, but all references 135 to "MLD proxy" should be understood to also include "IGMP/MLD proxy" 136 functionality. 138 As shown in Figure 1, MAG1 may connect to both unicast and multicast 139 LMAs. Thus, a given MN may simultaneously receive both unicast and 140 multicast traffic. In Figure 1, MN1 and MN2 receive unicast traffic, 141 multicast traffic, or both, whereas MN3 receives multicast traffic 142 only. 144 +--------------+ 145 |Content Source| 146 +--------------+ 147 | 148 | 149 *** *** *** *** *** *** *** *** 150 * ** ** ** * * ** ** ** * 151 * * * * 152 * Unicast Traffic * * Multicast Traffic * 153 * * * * 154 * ** ** ** * * ** ** ** * 155 *** *** *** *** *** *** *** *** 156 | | 157 | | 158 | | 159 +-----+ +------+ 160 Unicast | LMA1| | LMA2 | Multicast 161 Anchor +-----+ +------+ Anchor 162 \\ // || 163 \\ // || 164 \\ // || 165 \\ // || 166 \\ // || 167 \\ // || 168 \\ // || 169 \\ // || 170 \\ // || 171 +-----+ +-----+ 172 | MAG1| | MAG2| MLD Proxy 173 +-----+ +-----+ 174 | | | 175 | | | 176 {MN1} {MN2} {MN3} 178 Figure 1 Architecture of Dedicated LMA as Multicast Anchor 180 3.2. Multicast Establishment 182 Figure 2 shows the procedure when MN1 attaches to MAG1, and 183 establishes associations with LMA1 (unicast) and LMA2 (multicast). 185 MN1 MAG1 LMA1 LMA2 186 | (MLD Proxy) (Unicast) (Multicast) 187 MN attaches to MAG1 | | | 188 | | | | 189 |------Rtr Sol----- ->| | | 190 | |--PBU -- >| | 191 | | | | 192 | |<-- PBA --| | 193 | | | | 194 | |=Unicast= | | 195 | | Tunnel | | 196 |<-----Rtr Adv ------ | | | 197 | | | | 198 |< ------ Unicast Traffic------ >| | 199 | | | | 200 MN requires multicast services | | 201 | | | | 202 |---MLD Report (G) -->| | | 203 | | | | 204 | |---- Aggregated ---> | 205 | | MLD Report (G) | 206 | | | | 207 | |==Multicast Tunnel ==| 208 | | | | 209 | | | | 210 |< --------- Multicast Traffic ----------- >| 211 | | | | 213 Figure 2 MN Attachment and Multicast Service Establishment 215 In Figure 2, MAG1 first establishes the PMIPv6 tunnel with LMA1 for 216 unicast traffic as defined in [RFC5213] after being triggered by the 217 Router Solicitation message from MN1. Also, MN1 sends the MLD report 218 message (when required by its upper layer applications) as defined in 219 [RFC3810]. MAG1 acting as a MLD Proxy as defined in [RFC4605] will 220 then send an Aggregated MLD Report to the multicast anchor, LMA2. 221 This will then trigger establishment of a multicast tunnel between 222 MAG1 and LMA2. 224 3.3. Multicast Mobility 226 Figure 3 illustrates the mobility scenario for multicast traffic. 227 Specifically, MN2 with ongoing multicast subscription moves from MAG1 228 to MAG2. Note that in this scenario MAG2 is connected only to LMA2 229 (multicast) and does not receive unicast traffic. Of course, if it 230 was desired to support unicast traffic, the architecture will easily 231 allow MAG2 to also connect to LMA1 to support unicast traffic. 233 After MN2 mobility, MAG2 acting in its role of MLD proxy will send an 234 MLD Query to the newly observed MN on its downlink. Assuming that 235 the subsequent MLD Report from MN2 requests membership of a new 236 multicast group (from MAG2's point of view), this will then result in 237 an Aggregated MLD Report being sent to LMA2 from MAG2. 239 When MN2 detaches, MAG1 may keep the multicast tunnel with the 240 multicast LMA2 if there are still other MNs using the multicast 241 tunnel. Even if there are no MNs currently on the multicast tunnel, 242 MAG1 may decide to keep the multicast tunnel for potential future 243 use. 245 MN2 MAG1 MAG2 LMA1 LMA2 246 | (MLD Proxy) (MLD Proxy) (Unicast)(Multicast) 247 | | | | | 248 MN Attached | | | | 249 To MAG1 | | | | 250 | | | | | 251 | |========= Multicast Tunnel ======= | 252 | | | | | 253 MN Detaches | | | | 254 From MAG1 | | | | 255 | | | | | 256 | | | | | 257 MN Attaches | | | | 258 To MAG2 | | | | 259 | | | | | 260 |---------Rtr Sol------ >| | | 261 | | | | | 262 |<-----Rtr Adv --------- | | | 263 | | | | | 264 | | | | | 265 |<---------MLD Query---- | | | 266 | | | | | 267 |---MLD Report (G) ----> | | | 268 | | | | | 269 | | |---- Aggregated -----> | 270 | | | MLD Report (G) | 271 | | | | | 272 | | |==Multicast Tunnel === | 273 | | | | | 274 | | | | | 275 |< --------- Multicast Traffic ---------------- >| 276 | | | | | 277 | | | | | 279 Figure 3 Multicast Mobility Signaling 281 3.4. Advantages 283 One of the main advantages of the proposed architecture of a 284 dedicated multicast LMA, and MAGs acting as a Proxy MLD, is that it 285 allows a PMIPv6 domain to closely follow a simple multicast tree 286 topology for Proxy MLD forwarding (cf., sections 1.1 and 1.2 of 287 [RFC4605]). 289 Another major advantage is that a dedicated multicast LMA minimizes 290 replication of multicast packets compared to a combined 291 unicast/multicast LMA as proposed in [I-D.schmidt-multimob-pmipv6- 292 mcast-deployment]. Figures 4 and 5 illustrate this point visually. 293 For this simple scenario, it can be observed that the dedicated 294 multicast LMA topology (Figure 4) generates 6 packets for one input 295 multicast packet. In comparison, the combined unicast/multicast LMA 296 topology (Figure 5) generates 8 packets for one input multicast 297 packet. 299 In general, it can be seen that the extra multiplication of packets 300 in the combined unicast/multicast LMA topology will be proportional 301 to the number of LMAs, and the number of MNs (in a given MAG) 302 associated to different LMAs. The packet multiplication problem 303 aggravates as more MNs associated to different LMAs receive the same 304 multicast traffic when attached to the same MAG. Hence, the 305 dedicated multicast architecture significantly decreases the network 306 capacity requirements. 308 (Note that in Figure 4, it is assumed that MN1 and MN2 are associated 309 with MAG1-LMA1, and MN3 is associated with MAG2-LMA2 for multicast 310 traffic. In Figure 5, it is assumed that MN1 is associated with 311 MAG1-LMA1, MN2 is associated with MAG1-LMA2, and MN3 is associated 312 with MAG2-LMA2 for multicast traffic. In both Figures 4 and 5, it is 313 assumed that the packets are transmitted point to point on the last 314 hop wireless link.) 315 +--------------+ 316 |Content Source| 317 +--------------+ 318 | 319 | 320 +---+ Packet destined 321 | 1 | for Multicast group "G" 322 +---+ 323 | 324 *** *** *** *** *** *** *** *** 325 * ** ** ** * * ** ** ** * 326 * * * * 327 * Unicast Traffic * * Multicast Traffic * 328 * * * * 329 * ** ** ** * * ** ** ** * 330 *** *** *** *** *** *** *** *** 331 | | 332 | +---+ 333 | | 2 | 334 | +---+ 335 | | 336 +-----+ +------+ 337 Unicast | LMA1| | LMA2 | Multicast 338 Anchor +-----+ +------+ Anchor 339 \\ //|| 340 \\ // || 341 \\ // || 342 \\ // || 343 \\ +---+ +---+ 344 \\ | 3 | | 4 | 345 \\ +---+ +---+ 346 \\ // || 347 \\ // || 348 \\ // || 349 \\ // || 350 +-----+ +-----+ 351 | MAG1| | MAG2| MLD Proxy 352 +-----+ +-----+ 353 | | | 354 +---+ +---+ +---+ 355 | 5 | | 6 | | 7 | 356 +---+ +---+ +---+ 357 | | | All MNs in same 358 | | | multicast group "G" 359 {MN1} {MN2} {MN3} 361 Figure 4 Packet Flow in a Dedicated Multicast LMA 362 +--------------+ 363 |Content Source| 364 +--------------+ 365 | 366 | 367 +---+ Packet destined 368 | 1 | for Multicast group "G" 369 +---+ 370 | 371 *** *** *** *** *** *** *** *** *** 372 * ** ** ** ** ** ** ** ** * 373 * * 374 * Fixed Internet * 375 * (Unicast & Multicast Traffic) * 376 * ** ** ** ** ** ** ** ** * 377 *** *** *** *** *** *** *** *** *** 378 | | 379 +---+ +---+ 380 | 2 | | 3 | 381 +---+ +---+ 382 | | 383 +-----+ +------+ 384 | LMA1| | LMA2 | Combined 385 +-----+ +------+ Unicast/Multicast 386 \\ // || Anchor 387 \\ // || 388 \\ // || 389 \\ // || 390 +---+ +---+ +---+ 391 | 4 | | 5 | | 6 | 392 +---+ +---+ +---+ 393 \\ // || 394 \\ // || 395 \\ // || 396 \\ // || 397 +-----+ +-----+ 398 | MAG1| | MAG2| MLD Proxy 399 +-----+ +-----+ 400 | | | 401 +---+ +---+ +---+ 402 | 7 | | 8 | | 9 | 403 +---+ +---+ +---+ 404 | | | All MNs in same 405 | | | multicast group "G" 406 {MN1} {MN2} {MN3} 408 Figure 5 Packet Flow in a Combined Unicast/Multicast LMA 410 4. Security Considerations 412 This draft discusses the operations of existing protocols without 413 modifications. It does not introduce new security threats beyond the 414 current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], 415 IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605]. 417 5. IANA Considerations 419 This document makes no request of IANA. 421 6. References 423 6.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 429 Syntax Specifications: ABNF", RFC 2234, Internet Mail 430 Consortium and Demon Internet Ltd., November 1997. 432 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 433 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 435 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 436 in Ipv6", RFC 3775, June 2004. 438 [RFC3810] Vida, R. and L.Costa, "Multicast Listener Discovery Version 439 2 (MLDv2) for IPv6", RFC 3810, June 2004. 441 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 442 Thyagarajan, "Internet Group Management Protocol, Version 443 3", RFC 3376, October 2002. 445 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 446 Group Management Protocol (IGMP)/ Multicast Listener 447 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD 448 Proxying")", RFC 4605, August 2006. 450 6.2. Informative References 452 [I-D.deng-multimob-pmip6-requirement] 453 Deng, H., Schmidt, T., Seite, P., and P.Yang, "Multicast 454 Support Requirements for Proxy Mobile IPv6", draft-deng- 455 multimob-pmip6-requirements-02 (Work in progress), July 13, 456 2009. 458 [I-D.schmidt-multimob-pmipv6-mcast-deployment-03] Schmidt, TC., 459 Waehlisch, M., Sarikaya, B., and S.Krishnan, "A Minimal 460 Deployment Option for Multicast Listeners in PMIPv6 461 Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-03 462 (Work in progress), December 16, 2009. 464 7. Acknowledgments 466 This document was prepared using 2-Word-v2.0.template.dot. 468 Authors' Addresses 470 Juan Carlos Zuniga 471 InterDigital Communications, LLC 472 Email: JuanCarlos.Zuniga@InterDigital.com 474 Guang Lu 475 InterDigital Communications, LLC 476 Email: Guang.Lu@InterDigital.com 478 Akbar Rahman 479 InterDigital Communications, LLC 480 Email: Akbar.Rahman@InterDigital.com