idnits 2.17.1 draft-sfigueiredo-multimob-use-case-dmm-03.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 are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4203 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-02 == Outdated reference: A later version (-09) exists of draft-ietf-multimob-pmipv6-source-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MULTIMOB Group S. Figueiredo 2 Internet Draft Universidade de Aveiro 3 Intended status: Informational S. Jeon 4 Expires: April 22, 2013 Instituto de Telecomunicacoes 5 R. L. Aguiar 6 Universidade de Aveiro 7 October 22, 2012 9 IP Multicast Use Cases and Analysis over Distributed Mobility 10 Management 12 draft-sfigueiredo-multimob-use-case-dmm-03.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute 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 any 25 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 This Internet-Draft will expire on April 22, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 Mobile networks are changing towards distributed mobility management 54 (DMM), tackling inefficiencies of existing mobility protocols 55 regarding network management and packet routing. Identifying IP 56 multicast use cases applicable to DMM is a logical step before 57 exploring solution spaces. This document describes use cases where IP 58 multicast is applied in DMM environments, considering two main 59 deployment options: multicast router or MLD-Proxy deployment at a 60 Mobility Access Router (MAR). Due to the lack of standard terminology, 61 we refer to MAR as the entity embedding mobility-related functions, 62 e.g. providing network access and flow anchoring capabilities. Each 63 deployment option is thoroughly analyzed regarding its advantages and 64 disadvantages, and both multicast listener and source mobility 65 support are considered. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Conventions and Terminology....................................3 71 3. Use Cases Description..........................................4 72 3.1. Assumptions...............................................4 73 3.2. Mobile Multicast listener.................................5 74 3.2.1. MLD Proxy deployment at MAR..........................5 75 3.2.1.1. Operation.......................................5 76 3.2.1.2. Detailed analysis...............................6 77 3.2.2. Multicast Router deployment at MAR...................8 78 3.2.2.1. Operation.......................................8 79 3.2.2.2. Detailed analysis...............................8 80 3.3. Multicast sender support..................................9 81 3.3.1. MLD Proxy deployment at MAR..........................9 82 3.3.1.1. Operation.......................................9 83 3.3.1.2. Detailed analysis..............................10 84 3.3.2. Multicast Router deployment at MAR..................14 85 3.3.2.1. Operation......................................14 86 3.3.2.2. Detailed analysis..............................14 87 3.4. Summary of analysis......................................15 88 4. IANA Considerations...........................................16 89 5. Security Considerations.......................................16 90 6. References....................................................17 91 6.1. Normative References.....................................17 92 6.2. Informative References...................................17 94 1. Introduction 96 Centralized mobility management approach brings several drawbacks 97 such as non-optimal routing or severe overloading on the anchor point. 98 Such problems are expected to be more severe as mobile devices data 99 consumption (and generation) increases. 101 In order to tackle these problems, the concept of distributed 102 mobility management (DMM) has emerged. It couples per flow and 103 distributed anchoring, bringing the mobility anchor closer to the MN. 105 IP multicast, as one of the enablers for efficient distribution of 106 multimedia content, is composed of two main functions: multicast 107 routing and membership subscription. When those are coupled with IP 108 mobility, it is very critical to know possible use cases and 109 respective issues, since those techniques were mainly designed for 110 fixed networks. 112 This document presents possible use cases of IP multicast in a DMM 113 environment, by aligning to DMM Requirements [DMMREQ]. The different 114 use cases result from the different functionalities provided at the 115 MAR - MLD Proxy or MR -, and both mobile listener and sender support 116 are analyzed. The goal was to identify the advantages (e.g. ease of 117 deployment, resource-lightness) and constrains (e.g. lack of resource 118 efficiency, non-optimal routing) of each deployment option, 119 considering its impact for the support of mobile sender or mobile 120 listeners. 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], [RFC6275], 129 and [RFC3810], and [RFC4601]. Also, new entities are defined relying 130 on the PMIPv6 entities specified in [RFC5213]: 132 - Mobility Access Router (MAR): A router with the capability of 133 acting both as a mobility anchor and as an access router, in a per 134 flow basis. It can act as either a P-MAR, a N-MAR, or both. 136 - Previous Mobility Access Router (P-MAR): The MAR where the MN was 137 attached to previously to the IP mobility event, and which is 138 acting as an anchor for one or multiple flows. 140 - New Mobility Access Router (N-MAR): The MAR to which the MN is 141 currently attached. It provides the network access and thus 142 delivers all the flows destined to the MN's HNPs - including those 143 anchored to previously visited P-MARs. 145 - Multicast Listener Discovery Proxy (MLD-P): An entity providing 146 MLD based forwarding following the operation defined in [RFC4605]. 147 In the current document, only MLDv2-based signaling is considered, 148 targeting IPv6 networks (REQ3 from [DMMREQ]). 150 3. Use Cases Description 152 We identify different use cases that result from the application of 153 existing standards for IP multicast support over mobile environments. 154 We first consider mobile multicast listeners and then mobile 155 multicast senders, and for each case we analyze the impact of 156 deploying distinct functionality at the MAR: either MLD Proxy or 157 Multicast Router (namely PIM-SM capability). 159 3.1. Assumptions 161 A1: This draft refers to the requirements in [DMMREQ] as the base DMM 162 framework. 164 A2: Network access and data anchor functionalities are based in 165 [RFC5213], and are assumed to be provided by a Mobility Access Router 166 (MAR). 168 A3: It is assumed that when the IP mobility happens, at least one 169 multicast flow is being received (listener) / sent (sender). and a 170 mobility tunnel will be created between the P-MAR and the N-MAR. 172 A4: Using MLD Proxy, and when a user without mobility session starts 173 a multicast session at a MAR, the upstream interface of MLD Proxy is 174 configured towards an upstream multicast router in the multicast 175 infrastructure. But when a user moves to another MAR (N-MAR), under 176 assumption A3, the upstream interface of MLD Proxy will be configured 177 towards the anchor that enables unicast IP address continuity to be 178 kept (P-MAR, analogous to LMA function). 180 A5: Mobility occurs within a single PIM-SM multicast routing domain. 182 3.2. Mobile Multicast listener 184 3.2.1. MLD Proxy deployment at MAR 186 3.2.1.1. Operation 188 In this use case, MLD Proxy is considered as being deployed at all 189 MARs, and operating in an analogous way to the Base Multicast support 190 solution for PMIPv6 [RFC4605]. As such, after mobility, the upstream 191 interface MUST be configured towards the mobility tunnel endpoint, 192 i.e., P-MAR. 194 When a MN initially attaches to the P-MAR (as shown in Figure 1), it 195 receives a HNP address which will be associated with communications 196 started at that MAR. As the P-MAR detects the new logical link, it 197 transmits a General MLD Query message to which the MN will not yet 198 reply, as it is not yet running any multicast session. The P-MAR then 199 adds the downstream logical link to the MLD Proxy instance [RFC4605]. 200 In this case, i.e. when users subscribe to multicast content only 201 after associating with the MAR, the MLD Proxy will set its uplink to 202 the multicast infrastructure. When the MN intends to start receiving 203 the multicast session, it will send an unsolicited MLD Report, 204 triggered by its application. On receiving the latter message, the 205 MLD Proxy tries to join the multicast channel(s) by sending an 206 aggregated MLD Report through the MLD Proxy upstream interface. Note 207 that the same MLD Proxy instance will be assigned to all MNs which 208 initiated their multicast subscriptions in the current MAR (i.e. the 209 MNs having no multicast mobility session). When the joining procedure 210 ends, multicast data is transmitted through the same interfaces, 211 until reaching the MN. 213 +----------------+ 214 | Multicast | 215 | Infrastructure | 216 +----------------+ 217 * 218 * (S,G) 219 * 220 +----------+ +----------+ 221 | P-MAR |---------------| N-MAR | 222 | |***************| | 223 | (MLD-P) |---------------| (MLD-P) | 224 +----------+ +----------+ 225 * * 226 * * 227 +------+ +------+ 228 | MN | -----> | MN | 229 +------+ +------+ 231 Figure 1 Multicasting architecture using distributed mobility 232 management 234 When the MN moves from P-MAR, the N-MAR is required to establish a 235 tunnel for IP session continuity of the flows being sent towards and 236 from the MN's HNP assigned by the P-MAR. This implies that N-MAR has 237 an appropriate method to know the P-MAR. Multiple ideas are supposed 238 to be made at the solution stage of DMM WG, therefore it is out of 239 scope of this document. Following the operation of the MLD Proxy 240 [RFC4605], after the bidirectional tunnel establishment, the 241 following process takes place. First, the N-MAR sends a General MLD 242 Query, and verifies whether the MN is admissible for multicast 243 sessions. Then, the MLD Proxy at the N-MAR adds the downstream 244 interface corresponding to the MN, and configures the upstream 245 interface towards the MN's P-MAR, i.e. the tunnel endpoint. 247 3.2.1.2. Detailed analysis 249 This scheme is simple and directly applicable to a network-based 250 multicast DMM approach, as no extensions for multicast-related 251 operation are required. Besides, the MLDv2 Proxy was devised with a 252 less resource-demanding nature compared to MRs, aimed for scenarios 253 where multicast routing is not beneficial or required. The same 254 applies in DMM scenarios. However, this approach leads to a couple of 255 relevant issues. Traffic duplication is the result of the tunnel 256 convergence problem, occurring e.g. in [RFC6224]. As shown in Figure 257 2, MN1 and MN3, which moved from MAR1 and MAR3, respectively, are 258 currently located at the MAR2. Through their respective tunnels, they 259 receive multicast packets of the same channel through different 260 anchoring MARs. This causes duplicated traffic to converge to the 261 MAR2. Concretely, the magnitude of replicated traffic is expected to 262 be much higher than that of PMIPv6, considering the consequences of 263 having a single mobility entity coupling anchoring and network access 264 provision: we assume that the number of MARs in future DMM domains 265 will be much larger than that of LMAs at core level within a PMIPv6 266 domain. 268 +----------------+ 269 | Multicast Tree | * 270 +----------------+ * 271 * * * 272 * * * 273 * * * 274 (S,G) * (S,G) * * (S,G) 275 * * * 276 +----------+ (-->) +----------+ (<--) +----------+ 277 | MAR1 |---------| MAR2 |---------| MAR3 | 278 | |*********| |*********| | 279 | (MLD-P) |---------| (MLD-P) |---------| (MLD-P) | 280 +----------+ Tun.1 +----------+ Tun.2 +----------+ 281 * * * 282 * * * 283 * * * 284 +---+ move +---+ +---+ +---+ move +---+ 285 |MN1| ---> |MN1| |MN2| |MN3| <--- |MN3| 286 +---+ +---+ +---+ +---+ +---+ 288 (<--/-->) : direction of the multicast packet flow 290 Figure 2 Data replication 292 Another issue is non-optimal routing (Figure 3). If we consider a 293 significantly large domain, multicast packets may traverse a long 294 distance, depending on the setup direction of the upstream interface 295 of MLD Proxy instances. The issue is more noticeable if we assume all 296 MARs are connected to the multicast infrastructure. 298 When MLD Proxy is used in mobile multicast, low performance handover 299 will result from the need of going through the following process: 1) 300 MLD Proxy sets up the new MLD interface, 2) MLD Proxy sends the 301 General MLD Query, 3) MN sends the MLD Report. Only then MN will 302 receive the content, which for a significant number of IP multicast- 303 based applications, will represent a noticeable service disruption. 305 +----------------+ 306 | Multicast | 307 | Infrastructure | 308 +----------------+ 309 * 310 * (S,G) 311 * 312 +----------+ +----------+ 313 | P-MAR |------ ------| N-MAR | 314 | |****** ... ******| | 315 |(MLD-P) |------ ------| (MLD-P) | 316 +----------+ +----------+ 317 * * 318 * * 319 +------+ +------+ 320 | MN | -----> | MN | 321 +------+ +------+ 323 Figure 3 Non-optimal routing problem 325 3.2.2. Multicast Router deployment at MAR 327 3.2.2.1. Operation 329 In this use case, PIM-SM is deployed at all MARs. After the MN 330 attaches to a MAR, its PIM instance will act as the Designated Router 331 (DR) for the MN (and all other attached nodes). The procedure for 332 multicast subscription will be the same as in a fixed network, i.e. 333 the MN sends the Explicit MLD Report, and the MR at the MAR will 334 process that message and join any multicast channel if needed. 336 When the MN moves, the mobility tunnel will be setup between the two 337 MARs. As soon as the MN sends a MLD Report to the N-MAR, N-MAR will 338 join the multicast group / channel (if needed), the traffic will 339 start flowing from the tunnel and a new downstream state will be 340 configured. 342 3.2.2.2. Detailed analysis 344 An advantage of using MRs within MARs, is that multicast routing is 345 not affected due to RPF check. which leads to the selection of a 346 single upstream interface per MAR. This selection is independent of 347 the number of existing mobility tunnels. On the other hand, the usage 348 of MLD Proxy might lead to the tunneling of the same multicast group 349 to a common MAR, and might mean severe replication, similarly to 350 [RFC6224]. 352 As referred, although the mobility tunnel is activated after the MN 353 mobility, N-MAR will only subscribe the required multicast group / 354 channel after receiving the explicit MLD Report This can translate 355 into several lost packets, as the MN isn't aware of the mobility 356 process, and the General MLD Queries sent by MRs are periodic with a 357 varying frequency in the order of several seconds. Summarizing, 358 smooth handover cannot be assured without extending existing 359 mechanisms. When a MN moves to its N-MAR, there is the possibility 360 that the multicast channel(s) is (are) already being distributed 361 there. In such case, the new MAR will directly forward the multicast 362 traffic to the MN without using the tunnel for subscription function. 363 However, different MARs might be receiving common channels at 364 distinct times, which from the point of view from the receiver, will 365 result in frames replay (if receiving the same frames again) or miss 366 (in case the new MAR transmission is more advanced in time). 368 A possible non-efficiency is the unnecessary tunnel creation. 369 Following assumption A3, the tunnel is created due to the existence 370 of at least an ongoing multicast flow. The tunnel is created 371 independently of N-MAR's awareness to multicast subscriptions, 372 because the MLD Query occurs after its creation. Although, if the 373 subscription(s) of interest is (are) already being subscribed at the 374 N-MAR's MR, the tunnel will not be used at all for the multicast 375 subscription transmission. Thus, large scale creation of unnecessary 376 tunnels represents non-negligible wasted processing overhead. 378 3.3. Multicast sender support 380 3.3.1. MLD Proxy deployment at MAR 382 3.3.1.1. Operation 384 Sender mobility support is known to lead to service disruption 385 problems impacting all multicast tree, in particular if SPT is active. 386 In [SENDER], the utilization of MLD Proxy is proposed, being the 387 upstream interface always configured towards the fixed anchoring 388 entity - the LMA. To allow the sender to transmit multicast content 389 to the multicast tree in a DMM framework, the MLD Proxy should 390 configure its upstream interface towards a multicast router [PM-HOME]. 391 Depending on the network topology, it may also be configured towards 392 a MLD Proxy placed on a neighbor MAR. On the multicast source's 393 mobility (Figure 4), an identical operation to the listener mobility 394 case is expected from the MLD Proxy behavior. In this case, the 395 source uploads multicast traffic through one of MLD Proxy's 396 downstream interfaces, and the traffic is forwarded through the 397 uplink interface towards the P-MAR. 399 +------+ +----------------+ 400 | RP |---------| Multicast | 401 +------+ | Infrastructure | 402 * +----------------+ 403 * (S,G) | 404 * | 405 +----------+ +----------+ 406 | P-MAR |----------| N-MAR | 407 | |**********| | 408 | (MLD-P) |----------| (MLD-P) | 409 +----------+ +----------+ 410 * * 411 * * 412 +------+ +------+ 413 | S | ----> | S | 414 +------+ +------+ 416 Figure 4 Multicast sender mobility 418 3.3.1.2. Detailed analysis 420 The utilization of MLD Proxy carries the previously referred 421 advantages, as ease of deployment and operation lightness. 423 When a source moves to N-MAR from P-MAR, multicast data will be sent 424 through the mobility tunnel between N-MAR and P-MAR (Figure 5). If a 425 listener (L1) attaches to the same MAR (N-MAR), it will receive the 426 multicast data through multicast infrastructure, following the 427 configuration of MLD Proxy. Hence, the multicast data is routed non- 428 optimally between the source and the listener, going from N-MAR to P- 429 MAR, to the multicast routing tree, and then back to N-MAR again 430 before reaching the listener. 432 +------+ +----------------+ 433 | RP |*********| Multicast | 434 +------+ | Infrastructure | 435 * +----------------+ 436 * (S,G) * 437 * * 438 +----------+ +----------+ 439 | P-MAR |-------| N-MAR | 440 | |*******| | 441 | (MLD-P) |-------| (MLD-P) | 442 +----------+ +----------+ 443 * * * 444 * * * 445 +------+ move +------+ +-----+ 446 | S | ---> | S | | L1 | 447 +------+ +------+ +-----+ 449 Figure 5 Triangular routing after source mobility 451 A similar problem occurs in the opposite process, i.e. if a multicast 452 source starts transmitting multicast content at a MAR, and a listener 453 moves to the same MAR while receiving the source's content (Figure 454 6). 456 +------+ +----------------+ 457 | RP |*********| Multicast | 458 +------+ | Infrastructure | 459 * +----------------+ 460 * (S,G) * 461 * * 462 +----------+ +----------+ 463 | N-MAR |-------| P-MAR | 464 | |*******| | 465 | (MLD-P) |-------| (MLD-P) | 466 +----------+ +----------+ 467 * * * 468 * * * 469 +------+ +----+ move +----+ 470 | S | | L1 | <--- | L1 | 471 +------+ +----+ +----+ 473 Figure 6 Triangular routing after listener mobility (MLD-Proxy case) 474 When the source and the listener are within a same MAR (MAR2), if 475 both the source and listener try to send the session and receive it, 476 respectively, the traffic will be optimally sent to the listener 477 without going through native multicast infrastructure. As the traffic 478 reaches the MLD Proxy via the downstream interface to which the 479 source is attached, it will be sent through the downstream interface 480 to which the listener sent the MLD Report. However, if the source and 481 the listener move to different MARs, the traffic will traverse the 482 following non-optimal path, even though they share a common anchor: 484 Source -> MAR1 -> MAR2 -> Multicast Tree -> MAR2 -> MAR3 486 This problem is depicted in Figure 7. 488 +----------------+ 489 | Multicast Tree | 490 +----------------+ 491 * * 492 * * 493 * * 494 * * 495 * * 496 +----------+ (-->) +----------+ (-->) +----------+ 497 | MAR1 |---------| MAR2 |---------| MAR3 | 498 | |*********| |*********| | 499 | (MLD-P) |---------| (MLD-P) |---------| (MLD-P) | 500 +----------+ Tun.1 +----------+ Tun.2 +----------+ 501 * * * * 502 * * * * 503 * * * * 504 +---+ move +---+ +---+ move +---+ 505 | S | <--- | S | | L | --> | L | 506 +---+ +---+ +---+ +---+ 508 (<--/-->) : direction of the multicast packet flow 510 Figure 7 Multicast traffic non-optimal routing due to both mobile 511 sender and listener 513 REQ1 from [DMMREQ] refers that "DMM MUST enable a distributed 514 deployment of mobility management of IP sessions so that the traffic 515 can be routed in an optimal manner without traversing centrally 516 deployed mobility anchors". When a MN subscribes to a new multicast 517 session with existing multicast mobility session, the Aggregated MLD 518 Report containing all the MN's multicast subscriptions will be sent 519 from the current MLD Proxy through the same uplink interface, i.e. 520 towards a single multicast mobility anchor. This results in some of 521 previously identified issues (e.g. non-optimality in the path that 522 both the subscription and multicast traffic traverse). It can be 523 stated that the MLD Proxy nature doesn't comply with the 524 aforementioned requirement, leading to the subscription of any 525 multicast flow using the same multicast mobility data path. 527 This problem is depicted in Figure 8, where both multicast flow 1 and 528 flow 2 reach MAR2 from MAR1, being flow 2's optimal routing path 529 affected by the mobility status of the MN, and in particular by the 530 order in which the multicast flows were subscribed. While this issue 531 is not exclusively related to mobile multicast sources, it is better 532 depicted and its' impact in the routing is more obvious when 533 considering one. 535 +----------------+ 536 | Multicast Tree | 537 * +----------------+# 538 * # 539 * # 540 * # 541 * # 542 +----------+ (-->) +----------+ 543 | MAR1 |--------- -------| MAR2 | 544 | |#*#*#*#*#............#*#*#*#| | 545 | (MLD-P) |--------- -------| (MLD-P) | 546 +----------+ Tunnel (used after mob.) +----------+ 547 * * # 548 * downstream) # # (upstream) 549 * * # 550 * # # 551 +---+ move +---+ +---+ 552 | L | ----------> | L | | S | 553 +---+ +---+ +---+ 555 * : Multicast flow 1 556 # : Multicast flow 2 (subscribed after some time in MAR2) 558 Figure 8 Non-optimal routing due to single MLD Proxy uplink 560 3.3.2. Multicast Router deployment at MAR 562 3.3.2.1. Operation 564 When a source starts transmitting multicast traffic, the content will 565 be encapsulated in PIM-Register messages, and sent towards the RP 566 (e.g .statically configured or discovered through a Bootstrapping 567 Router (BSR)). In DMM, the RP can be a core MR or a MAR (including 568 the initial MAR). The RP's SPT and each of the DR's SPTs may then be 569 created. When the source moves, N-MAR's MR will create the state for 570 the new multicast group, and the traffic will be forwarded using the 571 tunnel to the P-MAR, until reaching the RP (unless it is the PIM 572 instance at the P-MAR itself). It is then sent down the RPT. Again, 573 the creation of the SPTs will typically be triggered following PIM-SM 574 regular operation. 576 3.3.2.2. Detailed analysis 578 In case the RP's Source Path Tree is built before the mobility 579 process, it will be destroyed due to mobility, and the tree 580 construction process will be reinitiated at the new MAR. Also, in 581 case the Shortest Path Tree between the listener's DRs and the 582 sender's DR is being used, mobility will reset the PIM process to the 583 RPT stage. This means that each sender mobility event results in 584 increased signaling overhead and delay as consequence of the 585 multicast routing convergence (i.e. Phase 2 and Phase 3 from PIM-SM 586 operation). Moreover, non-optimal routing occurs when the RPT is used. 587 When a sender moves to a MAR where listeners are subscribing to the 588 channel it is sending, the multicast traffic will always reach the N- 589 MAR by going through the RP (as shown in Figure 9). 591 Using PIM-SM in DMM scenarios there is a trade-off between the 592 routing non-optimality of RPT and the non-efficient consequences of 593 frequent SPT establishment. It is important to note that this impact 594 is magnified the more listener's DRs are receiving the multicast 595 channel(s). 597 +------+ +----------------+ 598 | RP |*********| Multicast | 599 +------+ | Infrastructure | 600 * +----------------+ 601 * (S,G) * 602 * * 603 +----------+ +----------+ 604 | P-MAR |-------| N-MAR | 605 | |*******| | 606 | (MR) |-------| (MR) | 607 +----------+ +----------+ 608 * * * 609 * * * 610 +------+ move +------+ +-----+ 611 | S | ---> | S | | L1 | 612 +------+ +------+ +-----+ 614 Figure 9 Triangular routing after source mobility (MR case) 616 3.4. Summary of analysis 618 Table I summarizes the previous analysis, globally depicting the 619 differences between MLD Proxy and MR over DMM. The relevant sections 620 for each feature are appended below, and the meaning of each feature 621 is extended afterwards. 623 =================================================================== 624 | Feature \ Function | MLD Proxy | Multicast Router | 625 =================================================================== 626 | Lightweight | Yes | No | 627 ------------------------------------------------------------------- 628 | Optimal | No | Yes (using SPT) | 629 | routing |(3.2.1.2)/ (3.3.1.2) | (3.3.2.2) | 630 ------------------------------------------------------------------- 631 | Efficient | No | Yes | 632 | distribution |(3.2.1.2)/ (3.3.1.2) | (3.2.2.2),(3.3.2.2) | 633 ------------------------------------------------------------------- 634 | Distributed | No | Yes | 635 | anchoring | (3.3.1.2) | (3.2.2.2) | 636 ------------------------------------------------------------------- 637 | Seamless mobility | No | No | 638 | (listener) | (3.2.1.2) | (3.2.2.2) | 639 ------------------------------------------------------------------- 640 | HO signaling | Low | High (when using SPT)| 641 | overhead |(3.2.1.2), (3.3.1.2) | (3.3.2.2) | 642 ------------------------------------------------------------------- 643 | Tunnel is | Doesn't apply | No | 644 | always used | | (3.2.2.2) | 645 =================================================================== 646 Table I. Comparison between MLD Proxy and MR deployment 648 The meaning of each of the entries is as follows: 650 Lightweight: this entry reflects whether the deployed multicast 651 feature has a resources-wise lightweight operation. 653 Optimal routing: This entry reflects whether optimal routing is 654 assured. 656 Efficient distribution: This entry reflects vulnerability to 657 multicast traffic replication. 659 Distributed anchoring: This entry assesses whether for a single MN, 660 different multicast streams can be anchored at different mobility 661 anchors or not. 663 Seamless mobility (listener): This entry reflects whether IP mobility 664 is seamless from the point of view of the mobile listener's 665 application. 667 HO signaling overhead: This entry assesses the amount of signaling 668 introduced by the IP mobility of a MN represents. This signaling may 669 be relative to the mobility protocol or the multicast routing 670 operation. 672 Tunnel is always used: This entry assesses whether the mobility 673 tunnel utilization is assured or not. 675 4. IANA Considerations 677 This document makes no request of IANA. 679 5. Security Considerations 681 TBD 683 6. References 685 6.1. Normative References 687 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 688 Requirement Levels", RFC 2119, March 1997. 690 [RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 691 in IPv6", RFC 6275, July 2011. 693 [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery 694 Version 2 (MLDv2) for IPv6," IETF RFC 3810, June 2004. 696 [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and 697 B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, August 2008. 699 [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet 700 Group Management Protocol (IGMP) / Multicast Listener 701 Discovery (MLD) Based Multicast Forwarding ("IGMP/MLD 702 Proxying")", IETF RFC 4605, August 2006. 704 [RFC4601] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, 705 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 706 Protocol Specification (Revised)", RFC 4601, August 2006. 708 6.2. Informative References 710 [RFC6224] T. Schmidt, M. Waehlisch, S. Krishnan, "Base Deployment for 711 Multicast Listener Support in PMIPv6 Domain", RFC 6224, 712 April 2011. 714 [DMMREQ] H. Chan, "Requirements of distributed mobility management", 715 draft-ietf-dmm-requirements-02 (work in progress), 716 September 2012. 718 [SENDER] T C. Schmidt et al, "Mobile Multicast Sender Support in 719 Proxy Mobile IPv6 (PMIPv6) Domains", draft-ietf-multimob- 720 pmipv6-source-01 (work in progress), July 2012. 722 [PM-HOME] S. Jeon, N. Kang, and Y. Kim, "Mobility Management based on 723 Proxy Mobile IPv6 for Multicasting Services in Home 724 Networks," IEEE Transactions on Consumer Electronics (TCE), 725 vol. 55, no. 3, pp. 1227-1232, August 2009. 727 Authors' Addresses 729 Sergio Figueiredo 730 Universidade de Aveiro 731 3810-193 Aveiro, Portugal 733 E-mail: sfigueiredo@av.it.pt 735 Seil Jeon 736 Instituto de Telecomunicacoes 737 Campus Universitario de Santiago 738 3810-193 Aveiro, Portugal 740 E-mail: seiljeon@av.it.pt 742 Rui L. Aguiar 743 Universidade de Aveiro 744 3810-193 Aveiro, Portugal 746 E-mail: ruilaa@ua.pt