idnits 2.17.00 (12 Aug 2021) /tmp/idnits38735/draft-zuniga-multimob-smspmip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC6224]), 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 == Line 318 has weird spacing: '... oo oo ...' == Line 319 has weird spacing: '... oo oo ...' == Line 398 has weird spacing: '... oo oo...' == Line 399 has weird spacing: '... oo oo ...' == Line 400 has weird spacing: '... oo oo ...' == (3 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 11, 2011) is 3960 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group J.C. Zuniga 3 INTERNET-DRAFT A. Rahman 4 Intended Status: Standards Track InterDigital Communications, LLC 5 Expires: January 2012 L.M. Contreras 6 C.J. Bernardos 7 Universidad Carlos III de Madrid 8 I. Soto 9 Universidad Politecnica de Madrid 10 July 11, 2011 12 Support Multicast Services Using Proxy Mobile IPv6 13 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and 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/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 The MULTIMOB group has specified a base solution to support IP 54 multicasting in a PMIPv6 domain [RFC6224]. In this document, an 55 enhancement is proposed to the base solution to use a multicast tree 56 mobility anchor as the topological anchor point for multicast 57 traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement 58 provides benefits such as reducing multicast traffic replication and 59 supporting different PMIPv6 deployments scenarios. 61 Table of Contents 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2 Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 65 3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 6 68 3.2.1 PMIPv6 domain with ratio 1:1 . . . . . . . . . . . . . 7 69 3.2.2 PMIPv6 domain with ratio N:1 . . . . . . . . . . . . . 7 70 3.2.3 PMIPv6 domain with ratio 1:N . . . . . . . . . . . . . 9 71 3.2.4 PMIPv6 domain with H-LMA . . . . . . . . . . . . . . 10 72 3.3 Multicast Establishment . . . . . . . . . . . . . . . . . 12 73 3.4 Multicast Mobility . . . . . . . . . . . . . . . . . . . 14 74 3.5 PMIPv6 enhancements . . . . . . . . . . . . . . . . . . . 15 75 3.5.1 New Binding Update List in MAG . . . . . . . . . . . 15 76 3.5.2 Policy Profile Information with Multicast Parameters 16 77 3.5.3 MAG to MTMA attach requirements . . . . . . . . . . 16 78 3.5.4. Data structure stored by MTMA . . . . . . . . . . . 16 79 3.6 Advantages . . . . . . . . . . . . . . . . . . . . . . . 16 80 4 Consideration of MAG as multicast router in the tunnel 81 interface to MTMA . . . . . . . . . . . . . . . . . . . . . . 20 82 5 Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 7.1 Normative References . . . . . . . . . . . . . . . . . . 20 86 7.2 Informative References . . . . . . . . . . . . . . . . . 21 87 Appendix A. Overhead analysis of the proposed MTMA architecture. 21 88 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1 Introduction 92 Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving 93 the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the 94 Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the 95 network and does the mobility management on behalf of the Mobile Node 96 (MN). The Local Mobility Anchor (LMA) is the home agent for the MN 97 and the topological anchor point. PMIPv6 was originally designed for 98 unicast traffic. 100 The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by 101 IPv4 hosts to report their IP multicast group memberships to 102 neighboring multicast routers. Multicast Listener Discovery (MLDv2) 103 [RFC3810] is used in a similar way by IPv6 routers to discover the 104 presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4605] 105 allows an intermediate (edge) node to appear as a multicast router to 106 downstream hosts, and as a host to upstream multicast routers. IGMP 107 and MLD related protocols were not originally designed to address IP 108 mobility of multicast listeners (i.e. IGMP and MLD protocols were 109 originally designed for fixed networks). 111 The MULTIMOB group has specified a base solution to support IP 112 multicast listener mobility in a PMIPv6 domain [RFC6224]. In this 113 document, an enhancement is proposed to the base solution to use a 114 multicast tree mobility anchor (MTMA) as the topological anchor point 115 for multicast traffic, while the MAG remains as an IGMP/MLD proxy. 116 This enhancement allows different PMIPv6 deployment scenarios. It 117 also eliminates the so called "Tunnel Convergence problem" where the 118 MAG may receive the same multicast packet from several LMAs. There 119 are no impacts to the MN to support multicast listener mobility from 120 this document. 122 2 Conventions and Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 This document uses the terminology defined in [RFC5213], [RFC3775], 129 and [RFC3810]. Specifically, the definition of PMIPv6 domain is 130 reused from [RFC5213] and reproduced here for completeness. 132 - Proxy Mobile IPv6 Domain (PMIPv6-Domain): Proxy Mobile IPv6 133 domain refers to the network where the mobility management of a 134 mobile node is handled using the Proxy Mobile IPv6 protocol as 135 defined in [RFC5213]. The Proxy Mobile IPv6 domain includes local 136 mobility anchors and mobile access gateways between which security 137 associations can be set up and authorization for sending Proxy 138 Binding Updates on behalf of the mobile nodes can be ensured. 140 In this draft we refine such definition from the point of view of the 141 kind of traffic served to the MN in the following way: 143 - PMIPv6 unicast domain: PMIPv6 unicast domain refers to the 144 network covered by one LMA for unicast service in such a way that 145 an MN using that service is not aware of mobility as it moves from 146 one MAG to another associated to that LMA regarding its unicast 147 traffic. 149 - PMIPv6 multicast domain: PMIPv6 multicast domain refers to the 150 network covered by one network element named MTMA (defined below) 151 for multicast service in such a way that an MN using that service 152 is not aware of mobility as it moves from one MAG to another. 154 This means that a PMIPv6 domain can have several PMIPv6 unicast 155 domains and PMIPv6 multicast domains. 157 Additionally, some other definitions are introduced, as follows. 159 - MTMA or multicast tree mobility anchor: an entity working as 160 topological anchor point for multicast traffic exclusively. 162 - H-LMA or Hybrid-LMA: an entity dedicated to both unicast and 163 multicast services, that is, it is able to work as both LMA and 164 MTMA simultaneously. 166 3 Solution 168 A PMIPv6 domain may handle data from both unicast and multicast 169 sources. This document addresses an optimization of the base solution 170 specified for multicast support in PMIPv6 domains [RFC6224] by 171 introducing a complementary network entity, named multicast tree 172 mobility anchor (MTMA), and defining the architecture and protocol 173 flows derived from it. An MTMA can be used to serve as the mobility 174 anchor for multicast traffic. The MTMA connects to the MAG as 175 described in [RFC6224] and it can reuse native PMIPv6 features such 176 as tunnel establishment and security [RFC5213], heartbeat [RFC5847], 177 etc. Unicast traffic will go normally to the LMAs in the PMIPv6 178 domain. 180 This section describes how the MTMA works in scenarios of MN 181 attachment and multicast mobility. We first concentrate on the case 182 of both LMA and MTMA defining a unique PMIPv6 domain, and then 183 different deployment scenarios are presented. 185 3.1 Architecture 187 Figure 1 shows an example of a PMIPv6 domain supporting multicast 188 mobility. LMA1 is dedicated to unicast traffic, and MTMA1 is 189 dedicated to multicast traffic. The tree mobility anchor MTMA1 can be 190 considered to be a form of upstream multicast router with tunnel 191 interfaces allowing remote subscription for the MNs. Note that there 192 can be multiple LMAs for unicast traffic (not shown in Figure 1) in a 193 given PMIPv6 domain. Similarly, more than one MTMAs can be deployed 194 by the operator (not shown in Figure 1). 196 Also in this architecture, all MAGs that are connected to the MTMA 197 must support the MLD proxy [RFC4605] function. Specifically in Figure 198 1, each of the MAG1-MTMA1 and MAG2-MTMA1 tunnel interfaces defines an 199 MLD proxy domain. The MNs are considered to be on the downstream 200 interface of the MLD proxy (in the MAG), and MTMA1 is considered to 201 be on the upstream interface (of the MAG) as per [RFC4605]. Note 202 that MAG could also be an IGMP proxy. For brevity this document will 203 refer primarily to MLD proxy, but all references to "MLD proxy" 204 should be understood to also include "IGMP/MLD proxy" functionality. 206 As shown in Figure 1, MAG1 may connect to both unicast (LMAs) and 207 multicast (MTMAs) entities. Thus, a given MN may simultaneously 208 receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 209 receive unicast traffic, multicast traffic, or both, whereas MN3 210 receives multicast traffic only, despite of that, this draft 211 considers that every MN demanding multicast-only services is 212 previously registered in a PMIPv6 unicast domain to get a unicast IP 213 address. This registration can be required also for several purposes 214 such as remote management, billing, etc. 216 +--------------+ 217 |Content Source| 218 +--------------+ 219 | 220 | 221 *** *** *** *** *** *** *** *** 222 * ** ** ** * * ** ** ** * 223 * * * * 224 * Unicast Traffic * * Multicast Traffic * 225 * * * * 226 * ** ** ** * * ** ** ** * 227 *** *** *** *** *** *** *** *** 228 | | 229 | | 230 | | 231 +-----+ +------+ 232 Unicast | LMA1| | MTMA1| Multicast 233 Anchor +-----+ +------+ Anchor 234 \\ // || 235 \\ // || 236 \\ // || 237 \\ // || 238 \\ // || 239 \\ // || 240 \\ // || 241 \\ // || 242 \\ // || 243 +-----+ +-----+ 244 | MAG1| | MAG2| MLD Proxy 245 +-----+ +-----+ 246 | | | 247 | | | 248 {MN1} {MN2} {MN3} 250 Figure 1. Architecture of Multicast Tree Mobility Anchor (MTMA) 252 3.2 Deployment Scenarios 254 From the network architecture point of view, there are several 255 options when considering the multicast tree mobility anchor (MTMA) 256 approach. These options can be distinguished in terms of the number 257 of LMAs and MTMAs present in a PMIPv6 domain and the service 258 relationship that a set of MNs gets from them, in the form of a "LMA 259 : MTMA" ratio. According to that, it is possible to differentiate the 260 following approaches: 262 - A set of MNs is served in a PMIPv6 domain by two entities, one 263 MTMA for multicast service, and one LMA for unicast, in such a way 264 that the ratio is 1:1 (one common PMIPv6 unicast and multicast 265 domain). 267 - A set of MNs is served in a PMIPv6 domain by several entities, 268 one MTMA for multicast service, while the others (LMAs) for 269 unicast, in such a way that the ratio is N:1 (N PMIPv6 unicast 270 domains coexist with a unique multicast domain). 272 - A set of MNs is served in a PMIPv6 domain by several entities, 273 one LMA for unicast, while the others (MTMAs) are devoted to 274 multicast service, in such a way that the ratio is 1:N (one single 275 PMIPv6 unicast domain coexists with multiple multicast domains). 277 Scenarios with an N:M ratio are considered to be a combination of the 278 previous ones. 280 3.2.1 PMIPv6 domain with ratio 1:1 282 This approach basically refers to the architecture presented in 283 figure 1. Within this approach, a common set of MNs is served by a 284 couple of entities, one LMA for unicast and one MTMA for multicast. 285 All the MNs of the set are served by these two elements as they move 286 in the PMIPv6 domain. 288 3.2.2 PMIPv6 domain with ratio N:1 290 This approach basically refers to the situation where a common set of 291 MNs is served by a unique MTMA for multicast service, but 292 simultaneously there are subsets from that group of MNs which are 293 served by distinct LMAs for unicast service as they move in the 294 PMIPv6 domain. Each particular MN association with the LMAs (unicast) 295 and MTMA (multicast) remains always the same as it moves in the 296 PMIPv6 domain. 298 Figure 2 shows the scenario here described. 300 +----------------+ +----------------+ 301 |Content Source A| |Content Source B| 302 +----------------+ +----------------+ 303 | | 304 | | 305 *** *** *** *** *** *** *** *** *** *** *** 306 * ** ** ** ** ** ** ** ** ** ** * 307 * * 308 * Fixed Internet * 309 * (Unicast & Multicast Traffic) * 310 * ** ** ** ** ** ** ** ** ** ** * 311 *** *** *** *** *** *** *** *** *** *** *** 312 | | | 313 | | | 314 | | | 315 +-------+ +-----------------+ +-------+ 316 | LMA1 | | MTMA2 | | LMA3 | 317 +-------+ +-----------------+ +-------+ 318 || \\ oo oo oo oo // || 319 || \\ oo oo oo oo // || 320 || \\ oo oo oo oo // || 321 || \\ oo oo oo oo // || 322 || \\oo oo oo oo // || 323 || \\ oo oo oo// || 324 || oo\\ oo oo // || 325 || oo \\ oo oo //oo || 326 || oo \\ oo oo // oo || 327 || oo \\ oo oo // oo || 328 +------+ +--------+ +--------+ +--------+ 329 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 330 +------+ +--------+ +--------+ +--------+ 331 | | | | | | | | 332 | | | | | | | | 333 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 335 Figure 2. PMIPv6 domain with ratio N:1 337 The figure 2 proposes an architecture where there are two entities 338 acting as LMAs, LMA1 and LMA3, while there is another one, named 339 MTMA2, working as multicast tree mobility anchor. LMA1 and LMA3 340 constitute two distinct unicast domains, whereas MTMA2 forms a single 341 multicast domain. The tunnels among MAGs and LMAs represented by 342 lines ("||") indicate a tunnel transporting unicast traffic, while 343 the tunnels among MAGs and MTMA2 depicted with circles ("o") show a 344 tunnel transporting multicast traffic. 346 In the figure it can be observed that all the MNs are served by MTMA2 347 for the incoming multicast traffic from sources A or B. However, 348 there are different subsets regarding unicast traffic which maintain 349 distinct associations within the PMIPv6 domain. For instance, the 350 subset formed by MN10, MN11, MN20 and MN21 is served by LMA1 for 351 unicast, and the rest of MNs are being served by LMA3. For the 352 scenario described above, the association between each MN and the 353 corresponding LMA and MTMA is permanently maintained. 355 3.2.3 PMIPv6 domain with ratio 1:N 357 This approach is related to a scenario where a common group of MNs is 358 served by a unique LMA for unicast service, but simultaneously there 359 are subsets from that group of MNs which are served by distinct MTMAs 360 for multicast service as they move in the PMIPv6 domain. Each 361 particular MN association with the LMA and MTMAs (unicast and 362 multicast respectively) remains always the same as it moves in the 363 PMIPv6 domain. 365 Figure 3 shows the scenario here described. 367 The figure 3 proposes an architecture where the LMA2 is the unique 368 LMA for a certain group of MNs, while there are two others entities, 369 MTMA1 and MTMA3, acting as MTMAs for different subsets of MNs of the 370 same group. MTMA1 and MTMA3 constitute two distinct multicast 371 domains, whereas LMA2 forms a single unicast domain. Each MTMA could 372 be devoted to carry on a different content (for instance, MTMA1 for 373 source A and MTMA3 for source B) or not. Looking at the picture, the 374 subset formed by MN10, MN11, MN20 and MN21 is served by MTMA1 for 375 multicast. The rest of MNs are being served by MTMA3 also for 376 multicast. Finally, all of them are served by LMA2 for unicast. For 377 the scenario described above, the association between each MN and the 378 corresponding LMA and MTMA is permanently maintained. 380 +----------------+ +----------------+ 381 |Content Source A| |Content Source B| 382 +----------------+ +----------------+ 383 | | 384 | | 385 *** *** *** *** *** *** *** *** *** *** *** 386 * ** ** ** ** ** ** ** ** ** ** * 387 * * 388 * Fixed Internet * 389 * (Unicast & Multicast Traffic) * 390 * ** ** ** ** ** ** ** ** ** ** * 391 *** *** *** *** *** *** *** *** *** *** *** 392 | | | 393 | | | 394 | | | 395 +-------+ +-----------------+ +-------+ 396 | MTMA1 | | LMA2 | | MTMA3 | 397 +-------+ +-----------------+ +-------+ 398 oo oo // || || \\ oo oo 399 oo oo // || || \\ oo oo 400 oo oo // || || \\ oo oo 401 oo oo // || || \\ oo oo 402 oo oo// || || \\ oo oo 403 oo oo || || \\oo oo 404 oo //oo || || \\ oo 405 oo // oo || || oo\\ oo 406 oo // oo || || oo \\ oo 407 oo // oo || || oo \\ oo 408 +------+ +--------+ +--------+ +--------+ 409 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 410 +------+ +--------+ +--------+ +--------+ 411 | | | | | | | | 412 | | | | | | | | 413 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 415 Figure 3. PMIPv6 domain with ratio 1:N 417 3.2.4 PMIPv6 domain with H-LMA 419 The H-LMA is defined as an entity which simultaneously transports 420 unicast and multicast service, that is, it simultaneously works as 421 LMA and MTMA. In the context of the MTMA solution, an H-LMA can play 422 the role of MTMA for an entire group of MNs in a PMIPv6 domain, while 423 acting simultaneously as LMA for a subset of them. The figure 4 424 adapts the PMIPv6 domain with ratio N:1 scenario of figure 2 to the 425 case where MTMA2 is an H-LMA, which serves multicast traffic to all 426 the MNs in the picture, and simultaneously, it is able to serve 427 unicast traffic to the subset formed by MN30, MN40 and MN41. 429 +----------------+ +----------------+ 430 |Content Source A| |Content Source B| 431 +----------------+ +----------------+ 432 | | 433 | | 434 *** *** *** *** *** *** *** *** *** *** *** 435 * ** ** ** ** ** ** ** ** ** ** * 436 * * 437 * Fixed Internet * 438 * (Unicast & Multicast Traffic) * 439 * ** ** ** ** ** ** ** ** ** ** * 440 *** *** *** *** *** *** *** *** *** *** *** 441 | | | 442 | | | 443 | | | 444 +-------+ +-----------------+ +-------+ 445 | LMA1 | | H-LMA | | LMA3 | 446 +-------+ +-----------------+ +-------+ 447 || \\ oo db db oo // || 448 || \\ oo db db oo // || 449 || \\ oo db db oo // || 450 || \\ oo db db oo // || 451 || \\oo db db oo // || 452 || \\ db db oo// || 453 || oo\\ db db // || 454 || oo \\ db db //oo || 455 || oo \\ db db // oo || 456 || oo \\ db db // oo || 457 +------+ +--------+ +--------+ +--------+ 458 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 459 +------+ +--------+ +--------+ +--------+ 460 | | | | | | | | 461 | | | | | | | | 462 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 464 Figure 4. PMIPv6 domain with H-LMA 466 Figure 4 presents a PMIPv6 network where there are two pure unicast 467 LMAs, LMA1 and LMA3, and a hybrid LMA, labeled as H-LMA in the 468 figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4. 469 The tunnels among MAGs and LMAs represented by lines ("||") indicate 470 a tunnel transporting exclusively unicast traffic, the tunnels 471 depicted with circles ("o") show a tunnel transporting exclusively 472 multicast traffic, and the tunnels with mixed lines and circles 473 ("db") describe a tunnel transporting both types of traffic 474 simultaneously. 476 All of the MNs in the figure receive the multicast traffic from H-LMA 477 (one single multicast domain), but it is possible to distinguish 478 three subsets from the unicast service perspective (that is, three 479 unicast domains). The first subset is the one formed by MN10, MN11 480 and MN 20, which receives unicast traffic from LMA1. A second subset 481 is the one formed by MN21 and MN30, which receives unicast traffic 482 from H-LMA. And finally, a third subset is built on MN31, MN40 and 483 MN41, which receives unicast traffic from LMA3. For the scenario 484 described above, the association between each MN and the 485 corresponding LMA and H-LMA is permanently maintained. 487 3.3 Multicast Establishment 489 Figure 5 shows the procedure when MN1 attaches to MAG1, and 490 establishes associations with LMA (unicast) and MTMA (multicast). 492 MN1 MAG1 LMA MTMA 493 | (MLD Proxy) (Unicast) (Multicast) 494 MN attaches to MAG1 | | | 495 | | | | 496 |------Rtr Sol----- ->| | | 497 | |--PBU -- >| | 498 | | | | 499 | |<-- PBA --| | 500 | | | | 501 | |=Unicast= | | 502 | | Tunnel | | 503 |<-----Rtr Adv ------ | | | 504 | | | | 505 |< ------ Unicast Traffic------ >| | 506 | | | | 507 | |==Multicast Tunnel ==| 508 | | | | 509 |<--MLD Query --------| | | 510 | | | | 511 MN requires | | | 512 multicast services | | | 513 | | | | 514 |---MLD Report (G) -->| | | 515 | | | | 516 | |---- Aggregated ---> | 517 | | MLD Report (G) | 518 | | | | 519 | | | | 520 |< --------- Multicast Traffic ----------- >| 521 | | | | 523 Figure 5. MN Attachment and Multicast Service Establishment 525 In Figure 5, MAG1 first establishes the PMIPv6 tunnel with LMA for 526 unicast traffic as defined in [RFC5213] after being triggered by the 527 Router Solicitation message from MN1. Unicast traffic will then flow 528 between MN1 and LMA. 530 For multicast traffic, a multicast tunnel may have been pre- 531 configured between MAG1 and MTMA. Or the multicast tunnel may be 532 dynamically established when the first MN appears at the MAG. 534 MN1 sends the MLD report message (when required by its upper layer 535 applications) as defined in [RFC3810] in response to an MLD Query 536 from MAG1. MAG1 acting as a MLD Proxy as defined in [RFC4605] will 537 then send an Aggregated MLD Report to the multicast anchor, MTMA 538 (assuming that this is a new multicast group which MAG1 had not 539 previously subscribed to). Multicast traffic will then flow from 540 MTMA towards MN1. 542 3.4 Multicast Mobility 544 Figure 6 illustrates the mobility scenario for multicast traffic. 545 Specifically, MN2 with ongoing multicast subscription moves from MAG1 546 to MAG2. Note that, for simplicity, in this scenario we only 547 consider the tunnel of MAG2 with MTMA (for multicast traffic) and we 548 assume that MN2 does not receive unicast traffic. Of course, if it 549 was desired to support unicast traffic, this is served by a tunnel 550 between MAG2 and LMA to transfer unicast traffic. 552 According to baseline solution signaling method described in 553 [RFC6224], after MN2 mobility, MAG2 acting in its role of MLD proxy 554 will send an MLD Query to the newly observed MN on its downlink. 555 Assuming that the subsequent MLD Report from MN2 requests membership 556 of a new multicast group (from MAG2's point of view), this will then 557 result in an Aggregated MLD Report being sent to MTMA from MAG2. This 558 message will be sent through a pre-established (or dynamically 559 established) multicast tunnel between MAG2 and MTMA. 561 When MN2 detaches, MAG1 may keep the multicast tunnel with the 562 multicast MTMA if there are still other MNs using the multicast 563 tunnel. Even if there are no MNs currently on the multicast tunnel, 564 MAG1 may decide to keep the multicast tunnel for potential future 565 use. 567 As discussed above, existing MLD (and Proxy MLD) signaling will 568 handle a large part of the multicast mobility management for the MN. 570 MN2 MAG1 MAG2 LMA MTMA 571 | (MLD Proxy) (MLD Proxy) (Unicast)(Multicast) 572 | | | | | 573 MN Attached | | | | 574 To MAG1 | | | | 575 | | | | | 576 | |========= Multicast Tunnel ======= | 577 | | | | | 578 MN Detaches | | | | 579 From MAG1 | | | | 580 | | | | | 581 | | | | | 582 MN Attaches | | | | 583 To MAG2 | | | | 584 | | | | | 585 | | |==Multicast Tunnel === | 586 | | | | | 587 |---------Rtr Sol------ >| | | 588 | | |--- PBU --->| | 589 | | | | | 590 | | |<-- PBA ----| | 591 |<-----Rtr Adv --------- | | | 592 | | | | | 593 | | | | | 594 |<---------MLD Query---- | | | 595 | | | | | 596 |---MLD Report (G) ----> | | | 597 | | | | | 598 | | |---- Aggregated -----> | 599 | | | MLD Report (G) | 600 | | | | | 601 |< --------- Multicast Traffic ---------------- >| 602 | | | | | 603 | | | | | 605 Figure 6. Multicast Mobility Signaling 607 3.5 PMIPv6 enhancements 609 This section describes the enhancements to the Proxy Mobile IPv6 610 [RFC5213] protocol required to support the MTMA architecture. 612 3.5.1 New Binding Update List in MAG 614 The Binding Update List in the MAG must be updated to be able to 615 handle the fact that more than one entity (i.e. LMA and MTMA) may be 616 serving the mobile node. 618 3.5.2 Policy Profile Information with Multicast Parameters 620 A given mobile node's policy profile information must be updated to 621 be able to store the IPv6 addresses of both the LMA and MTMA. 623 3.5.3 MAG to MTMA attach requirements 625 The MAG procedures must be updated to be able to handle simultaneous 626 attach for a given mobile node to both the LMA and MTMA. For example, 627 packets coming from a given mobile node must be screened to determine 628 if it should be sent to the LMA or to the MTMA. 630 3.5.4. Data structure stored by MTMA 632 The MTMA does not directly interact with the MNs attached to any of 633 the MAGs. The MTMA only manages the multicast groups subscribed per 634 MAG on behalf of the MNs attached to it. Having this in mind, the 635 relevant information to be stored in the MTMA should be the tunnel 636 interface identifier (tunnel-if-id) of the bi-directional tunnel for 637 multicast between the MTMA and every MAG (as stated in [RFC5213] for 638 the unicast case), the IP addresses of the multicast group delivered 639 per tunnel to each of the MAGs, and the IP addresses of the sources 640 injecting the multicast traffic per tunnel to the multicast domain 641 defined by the MTMA. 643 3.6 Advantages 645 An advantage of the proposed MTMA architecture is that it allows a 646 PMIPv6 domain to closely follow a simple multicast tree topology for 647 Proxy MLD forwarding (cf., sections 1.1 and 1.2 of [RFC4605]). In 648 contrast, the combined unicast/multicast LMA as proposed in [RFC6224] 649 will be a more complex set of trees. 651 Another advantage of the proposed dedicated multicast solution is 652 that it allows a gradual network upgrade of a PMIPv6 domain to 653 support multicast functionality. This is because the operator does 654 not have to upgrade all the LMAs in the network to support multicast 655 functionality. Only certain nodes (MTMAs), dedicated to multicast 656 support, will have to be upgraded to support the new multicast 657 functionality. Also, multiple deployment scenarios are supported as 658 required by the operator for expected traffic distributions. 660 A final advantage is that a specific multicast elements minimize the 661 replication of multicast packets (the Tunnel Convergence problem), in 662 certain scenarios, compared to [RFC6224]. Figures 7 and 8 illustrate 663 this point visually. For this simple scenario, it can be observed 664 that the multicast MTMA topology (Figure 7) generates 6 packets for 665 one input multicast packet. In comparison, the combined 666 unicast/multicast LMA topology (Figure 8) generates 8 packets for one 667 input multicast packet. 669 In general, it can be seen that the extra multiplication of packets 670 in the combined unicast/multicast LMA topology will be proportional 671 to the number of LMAs, and the number of MNs (in a given MAG) 672 associated to different LMAs, for a given multicast group. The 673 packet multiplication problem aggravates as more MNs associated to 674 different LMAs receive the same multicast traffic when attached to 675 the same MAG. Hence, the MTMA architecture significantly decreases 676 the network capacity requirements in this scenario. 678 (Note that in Figure 7, it is assumed that MN1 and MN2 are associated 679 with MAG1-LMA1, and MN3 is associated with MAG2-MTMA2 for multicast 680 traffic. In Figure 8, it is assumed that MN1 is associated with 681 MAG1-LMA1, MN2 is associated with MAG1-LMA2, and MN3 is associated 682 with MAG2-LMA2 for multicast traffic. In both Figures 7 and 8, it is 683 assumed that the packets are transmitted point to point on the last 684 hop wireless link.) 686 Additional results can be found in [ERCIM], where both solutions are 687 compared by simulation under realistic traffic conditions. It can be 688 shown that, for multicast traffic, the number of channels that a node 689 (LMA in the base solution, MTMA in the proposed multicast 690 architecture) has to serve does not decrease linearly with the 691 reduction of the number of MNs associated to that node. The key 692 factor is the set of channels subscribed by the MNs. In fact, as the 693 number of MNs increases in the PMIPv6 domain, we have less advantage 694 for having several nodes serving multicast, as each of them will 695 probably manage all the multicast channels (or at least the popular 696 ones) anyway. 698 +--------------+ 699 |Content Source| 700 +--------------+ 701 | 702 | 703 +---+ Packet destined 704 | 1 | for Multicast group "G" 705 +---+ 706 | 707 *** *** *** *** *** *** *** *** 708 * ** ** ** * * ** ** ** * 709 * * * * 710 * Unicast Traffic * * Multicast Traffic * 711 * * * * 712 * ** ** ** * * ** ** ** * 713 *** *** *** *** *** *** *** *** 714 | | 715 | +---+ 716 | | 2 | 717 | +---+ 718 | | 719 +-----+ +------+ 720 Unicast | LMA1| | MTMA2| Multicast 721 Anchor +-----+ +------+ Anchor 722 \\ //|| 723 \\ // || 724 \\ // || 725 \\ // || 726 \\ +---+ +---+ 727 \\ | 3 | | 4 | 728 \\ +---+ +---+ 729 \\ // || 730 \\ // || 731 \\ // || 732 \\ // || 733 +-----+ +-----+ 734 | MAG1| | MAG2| MLD Proxy 735 +-----+ +-----+ 736 | | | 737 +---+ +---+ +---+ 738 | 5 | | 6 | | 7 | 739 +---+ +---+ +---+ 740 | | | All MNs in same 741 | | | multicast group "G" 742 {MN1} {MN2} {MN3} 744 Figure 7. Packet Flow in the MTMA architecture 745 +--------------+ 746 |Content Source| 747 +--------------+ 748 | 749 | 750 +---+ Packet destined 751 | 1 | for Multicast group "G" 752 +---+ 753 | 754 *** *** *** *** *** *** *** *** *** 755 * ** ** ** ** ** ** ** ** * 756 * * 757 * Fixed Internet * 758 * (Unicast & Multicast Traffic) * 759 * ** ** ** ** ** ** ** ** * 760 *** *** *** *** *** *** *** *** 761 | | 762 +---+ +---+ 763 | 2 | | 3 | 764 +---+ +---+ 765 | | 766 +-----+ +------+ 767 | LMA1| | LMA2 | Combined 768 +-----+ +------+ Unicast/Multicast 769 \\ // || Anchor 770 \\ // || 771 \\ // || 772 \\ // || 773 +---+ +---+ +---+ 774 | 4 | | 5 | | 6 | 775 +---+ +---+ +---+ 776 \\ // || 777 \\ // || 778 \\ // || 779 \\ // || 780 +-----+ +-----+ 781 | MAG1| | MAG2| MLD Proxy 782 +-----+ +-----+ 783 | | | 784 +---+ +---+ +---+ 785 | 7 | | 8 | | 9 | 786 +---+ +---+ +---+ 787 | | | All MNs in same 788 | | | multicast group "G" 789 {MN1} {MN2} {MN3} 791 Figure 8. Packet Flow in a Combined Unicast/Multicast LMA 793 4 Consideration of MAG as multicast router in the tunnel interface to MTMA 795 In the architecture described before, all MAGs that are connected to 796 the MTMA are considered to act as MLD proxies. This follows the MAG 797 characterization provided in [RFC6224]. However, interesting 798 advantages can be derived from the fact of converting the MAG node in 799 a multicast router in the tunnel interface towards the MTMA, that is, 800 in implementing PIM protocol ([RFC4601], [RFC4607]) in the tunnel 801 interface, in case the MAG connects to more than one MTMA in the 802 PMIPv6 domain. 804 This could be the case, for instance, in which a PMIPv6 domain 805 provides access to MNs of different home networks, each home network 806 using a distinct MTMA to provide multicast service in the PMIPv6 807 domain. With the MAG working as a multicast router in the tunnel 808 interface, in a source-specific multicast scenario [RFC4607], the MAG 809 could send the PIM request to the corresponding MTMA based on the 810 multicast source address. 812 Another possible scenario for connecting more than one MTMA to a MAG 813 could be the case of a home network using different MTMAs to serve 814 different content over the same PMIPv6 domain for scalability 815 reasons, or as a way to provide backup in case of MTMA failure. 817 5 Security Considerations 819 This draft discusses the operations of existing protocols without 820 modifications. It does not introduce new security threats beyond the 821 current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], 822 IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605]. 824 6 IANA Considerations 826 This document makes no request of IANA. 828 7 References 830 7.1 Normative References 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, 836 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 837 2008. 839 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 840 in Ipv6", RFC 3775, June 2004. 842 [RFC3810] Vida, R. and L.Costa, "Multicast Listener Discovery 843 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 845 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 846 Thyagarajan, "Internet Group Management Protocol, Version 847 3", RFC 3376, October 2002. 849 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 850 "Internet Group Management Protocol (IGMP)/ Multicast 851 Listener Discovery (MLD)-Based Multicast Forwarding 852 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 854 [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, 855 S., Laganier, J., "Heartbeat Mechanism for Proxy Mobile 856 IPv6", RFC 5847, June 2010. 858 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 859 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 860 Protocol Specification (Revised)", RFC 4601, August 2006. 862 [RFC4607] Holbrook, H., and B. Cain, "Source-Specific Multicast for 863 IP", RFC 4607, August 2006. 865 7.2 Informative References 867 [RFC6224] Schmidt, T.C., Waehlisch, M., and S.Krishnan, "Base 868 Deployment for Multicast Listener Support in PMIPv6 869 Domains", RFC 6224, April 2011. 871 [ERCIM] L.M. Contreras, C.J. Bernardos, I. Soto, "On the 872 efficiency of a dedicated LMA for multicast traffic 873 distribution in PMIPv6 domains", 5th ERCIM Workshop in 874 eMobility, Vilanova i la Geltru, Spain, June 2011. 876 [ETSI] ETSI TS 102 034, "Digital Video Broadcasting (DVB); 877 Transport of MPEG-2 TS Based DVB Services over IP Based 878 Networks", v1.4.1, August, 2009. 880 Appendix A. Overhead analysis of the proposed MTMA architecture. 882 This appendix provides an analysis of the overhead introduced by the 883 proposed multicast architecture. In this solution an MTMA is used to 884 serve the multicast traffic to the MNs. The MAGs in the PMIPv6 domain 885 are connected to the MTMA through a tunnel which is used to deliver 886 the multicast flows subscribed by the MNs attached to the MAG. 888 A very common way for video delivery over IP networks is the 889 transport of MPEG-2 Transport Streams (TS) encapsulated in RTP/UDP/IP 890 datagrams, as described in [ETSI]. 892 An MPEG-2 transport stream is a packet of 188 bytes. So, an Ethernet 893 frame with 1500 bytes of payload can carry a maximum of up to 7 MPEG- 894 2 TS packets. 896 When encapsulating those 7 MPEG-2 TS packets in RTP/UDP/IP datagrams 897 we are forming a datagram of length 7*188 (MPEG-2 TS) + 12 (RTP) + 8 898 (UDP) + 40 (IPv6) = 1376 bytes. 900 In the proposed multicast architecture, such datagram should be 901 transported over the tunnel existing between a MAG and the MTMA. That 902 tunnel implies an IP-in-IP encapsulation, that is, an additional 40 903 byte length header should be added to the datagram. In this 904 situation, the overhead caused by the MTMA approach can be calculated 905 as 40 / (40 + 1376) = 2,8%. 907 This results in a minimal overhead derived from the use of the tunnel 908 between MTMA and MAG. 910 Author's Addresses 912 Juan Carlos Zuniga 913 InterDigital Communications, LLC 914 Email: JuanCarlos.Zuniga@InterDigital.com 916 Akbar Rahman 917 InterDigital Communications, LLC 918 Email: Akbar.Rahman@InterDigital.com 920 Luis M. Contreras 921 Universidad Carlos III de Madrid 922 Email: contreras.uc3m@gmail.com 924 Carlos J. Bernardos 925 Universidad Carlos III de Madrid 926 Email: cjbc@it.uc3m.es 928 Ignacio Soto 929 Universidad Politecnica de Madrid 930 Email: isoto@dit.upm.es