idnits 2.17.1 draft-schmidt-multimob-pmipv6-mcast-deployment-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 8, 2010) is 5190 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-17 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-09 == Outdated reference: A later version (-06) exists of draft-zuniga-multimob-smspmip-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T C. Schmidt 3 Internet-Draft HAW Hamburg 4 Intended status: BCP M. Waehlisch 5 Expires: August 12, 2010 link-lab & FU Berlin 6 S. Krishnan 7 Ericsson 8 February 8, 2010 10 A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains 11 draft-schmidt-multimob-pmipv6-mcast-deployment-04 13 Abstract 15 This document describes deployment options for activating multicast 16 listener functions in Proxy Mobile IPv6 domains without modifying 17 mobility and multicast protocol standards. Similar to Home Agents in 18 Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast 19 subscription anchor points, while Mobile Access Gateways provide MLD 20 proxy functions. In this scenario, Mobile Nodes remain agnostic of 21 multicast mobility operations. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on August 12, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 9 74 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 9 75 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10 76 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.5. Multicast Availability throughout the Access Network . . . 12 78 4.6. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12 79 5. Message Source and Destination Address . . . . . . . . . . . . 12 80 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15 89 Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 15 90 Appendix C. Comparative Evaluation of Different Approaches . . . 16 91 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by 97 network-based management functions that enable IP mobility for a host 98 without requiring its participation in any mobility-related 99 signaling. Additional network entities, i.e., the Local Mobility 100 Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for 101 managing IP mobility on behalf of the mobile node (MN). 103 With these routing entities in place, the mobile node looses 104 transparent end-to-end connectivity to the static Internet, and in 105 the particular case of multicast communication, group membership 106 management as signaled by the Multicast Listener Discovery protocol 107 [RFC3810], [RFC2710] requires a dedicated treatment at the network 108 side, see [I-D.deng-multimob-pmip6-requirement]. 110 Multicast routing functions need a careful placement within the 111 PMIPv6 domain to augment unicast transmission with group 112 communication services. [RFC5213] does not explicitly address 113 multicast communication, whereas bi-directional home tunneling, the 114 minimal multicast support arranged by MIPv6, cannot be applied in 115 network-based management scenarios: A mobility-unaware node will 116 experience no reason to initiate a tunnel with an entity of mobility 117 support. 119 This document describes options for deploying multicast listener 120 functions in Proxy Mobile IPv6 domains without modifying mobility and 121 multicast protocol standards. Similar to Home Agents in Mobile IPv6, 122 PMIPv6 Local Mobility Anchors serve as multicast subscription anchor 123 points, while Mobile Access Gateways provide MLD proxy functions. 124 Mobile Nodes in this scenario remain agnostic of multicast mobility 125 operations. Accrediting the problem space of multicast mobility 126 [I-D.irtf-mobopts-mmcastv6-ps], this document does not address 127 specific optimizations and efficiency improvements of multicast 128 routing in network-centered mobility beyond base potentials, as such 129 solutions would require changes to the base specification of 130 [RFC5213]. 132 2. Terminology 134 This document uses the terminology as defined for the mobility 135 protocols [RFC3775] and [RFC5213], as well as the multicast edge 136 related protocols [RFC3810] and [RFC4605]. 138 3. Overview 140 The reference scenario for multicast deployment in Proxy Mobile IPv6 141 domains is illustrated in Figure 1. 142 +-------------+ 143 | Content | 144 | Source | 145 +-------------+ 146 | 147 *** *** *** *** 148 * ** ** ** * 149 * * 150 * Fixed Internet * 151 * * 152 * ** ** ** * 153 *** *** *** *** 154 / \ 155 +----+ +----+ 156 |LMA1| |LMA2| Multicast Anchor 157 +----+ +----+ 158 LMAA1 | | LMAA2 159 | | 160 \\ //\\ 161 \\ // \\ 162 \\ // \\ Unicast Tunnel 163 \\ // \\ 164 \\ // \\ 165 \\ // \\ 166 Proxy-CoA1 || || Proxy-CoA2 167 +----+ +----+ 168 |MAG1| |MAG2| MLD Proxy 169 +----+ +----+ 170 | | | 171 MN-HNP1 | | MN-HNP2 | MN-HNP3 172 MN1 MN2 MN3 174 Figure 1: Reference Network for Multicast Deployment in PMIPv6 176 An MN in a PMIPv6 domain will decide on multicast group membership 177 management completely independent of its current mobility conditions. 178 It will submit MLD Report and Done messages following application 179 desires, thereby using its link-local source address and multicast 180 destination addresses according to [RFC3810], or [RFC2710]. These 181 link-local signaling messages will arrive at the currently active MAG 182 via one of its downstream local (wireless) links. A multicast 183 unaware MAG would simply discard these MLD messages. 185 To facilitate multicast in a PMIPv6 domain, an MLD proxy function 187 [RFC4605] needs to be deployed on the MAG that selects the tunnel 188 interface corresponding to the MN's LMA for its upstream interface 189 (cf., section 6 of [RFC5213]). Thereby, each LMA-to-MAG tunnel 190 interface defines an MLD proxy domain at the MAG, containing all 191 downstream links to MNs that share this LMA. According to standard 192 proxy operations, MLD Report messages will be forwarded under 193 aggregation up the tunnel interface to its corresponding LMA. 195 Serving as the designated multicast router or an additional MLD 196 proxy, the LMA will transpose any MLD message from a MAG into the 197 multicast routing infrastructure. Correspondingly, the LMA will 198 implement appropriate multicast forwarding states at its tunnel 199 interface. Traffic arriving for groups under subscription will 200 arrive at the LMA, which it will forward according to all its group/ 201 source states. In addition, the LMA will naturally act as an MLD 202 querier, seeing its downstream tunnel interfaces as multicast enabled 203 links. 205 At the MAG, MLD queries and multicast data will arrive on the 206 (tunnel) interface that is assigned to a group of access links as 207 identified by its Binding Update List (cf., section 6 of [RFC5213]). 208 As specified for MLD proxies, the MAG will forward multicast traffic 209 and initiate related signaling down the appropriate access links to 210 the MNs. In proceeding this way, all multicast-related signaling and 211 the data traffic will transparently flow from the LMA to the MN on an 212 LMA-specific tree, which is shared among the multicast sources. 214 In case of a mobility handover, the MN (unaware of IP mobility) will 215 refrain from submitting unsolicited MLD reports. Instead, the MAG is 216 required to maintain group memberships in the following way. On 217 observing a new MN on a downstream link, the MAG sends a General MLD 218 Query. Based on its outcome and the multicast group states 219 previously maintained at the MAG, a corresponding Report will be sent 220 to the LMA aggregating group membership states according to the proxy 221 function. Additional Reports can be omitted, whenever multicast 222 forwarding states previously established at the new MAG already cover 223 the subscriptions of the MN. 225 In summary, the following steps are executed on handover: 227 1. The MAG-MN link comes up and the MAG discovers the new MN. 229 2. Unicast address configuration and PMIPv6 binding are performed, 230 the MAG can determine the corresponding LMA. 232 3. Following IPv6 address configuration, the MAG SHOULD send an 233 (early) MLD General Query to the new downstream link as part of 234 its standard multicast-enabled router operations. 236 4. The MAG SHOULD determine whether the MN is admissible to 237 multicast services, and stop here otherwise. 239 5. The MAG adds the new downstream link to the MLD proxy instance 240 with up-link to the corresponding LMA. 242 6. The corresponding Proxy instance triggers an MLD General Query on 243 the new downstream link. 245 7. The MN Membership Reports arrive at the MAG, either in response 246 to the early Query or to that of the Proxy instance. 248 8. The Proxy processes the MLD Report, updates states and reports 249 upstream if necessary. 251 After Re-Binding, the LMA is not required to issue a General MLD 252 Query on the tunnel link to refresh forwarding states. Multicast 253 state updates SHOULD be triggered by the MAG, which aggregates 254 subscriptions of all its MNs (see the call flow in Figure 2). 256 MN1 MAG1 MN2 MAG2 LMA 257 | | | | | 258 | Join(G) | | | | 259 +--------------->| | | | 260 | | Join(G) | | | 261 | |<---------------+ | | 262 | | | | | 263 | | Aggregated Join(G) | | 264 | +================================================>| 265 | | | | | 266 | | Mcast Data | | | 267 | |<================================================+ 268 | | | | | 269 | Mcast Data | Mcast Data | | | 270 |<---------------+--------------->| | | 271 | | | | | 272 | | < Movement to MAG2 & PMIP Binding Update > | 273 | | | | | 274 | | |--- Rtr Sol -->| | 275 | | | | | 276 | | | MLD Query | | 277 | | |<--------------+ | 278 | | | | | 279 | | | Join(G) | | 280 | | +-------------->| | 281 | | | Aggregated Join(G) 282 | | | +===============>| 283 | | | | | 284 | | Mcast Data | | | 285 | |<================================================+ 286 | | | | Mcast Data | 287 | | | |<===============+ 288 | Mcast Data | | | | 289 |<---------------+ | Mcast Data | | 290 | | |<--------------+ | 291 | | | | | 293 Figure 2: Call Flow of Multicast-enabled PMIP 295 These multicast deployment considerations likewise apply for mobile 296 nodes that operate with its IPv4 stack enabled in a PMIPv6 domain. 297 PMIPv6 can provide an IPv4 home address mobility support 298 [I-D.ietf-netlmm-pmip6-ipv4-support]. Such mobile node will use IGMP 299 [RFC2236],[RFC3376] signaling for multicast, which is handled by an 300 IGMP proxy function at the MAG in an analogous way. 302 Following these deployment steps, multicast management transparently 303 inter-operates with PMIPv6. It is worth noting that multicast 304 streams can possibly be distributed on redundant paths that lead to 305 duplicate traffic arriving from different LMAs at one MAG, and can 306 cause multiple data transmissions from an MAG over one wireless 307 domain to different MNs (see Appendix C for further considerations). 309 4. Deployment Details 311 Multicast activation in a PMIPv6 domain requires to deploy general 312 multicast functions at PMIPv6 routers and to define its interaction 313 with the PMIPv6 protocol in the following way: 315 4.1. Operations of the Mobile Node 317 A Mobile Node willing to manage multicast traffic will join, maintain 318 and leave groups as if located in the fixed Internet. No specific 319 mobility actions nor implementations are required at the MN. 321 4.2. Operations of the Mobile Access Gateway 323 A Mobility Access Gateway is required to assist in MLD signaling and 324 data forwarding between the MNs which it serves, and the 325 corresponding LMAs associated to each MN. It therefore needs to 326 implement an instance of the MLD proxy function [RFC4605] for each 327 upstream tunnel interface that has been established with an LMA. The 328 MAG decides on the mapping of downstream links to a proxy instance 329 (and hence an upstream link to an LMA) based on the regular Binding 330 Update List as maintained by PMIPv6 standard operations (cf., section 331 6.1 of [RFC5213]). As links connecting MNs and MAGs change under 332 mobility, MLD proxies at MAGs MUST be able to dynamically add and 333 remove downstream interfaces in its configuration. 335 On the reception of MLD reports from an MN, the MAG MUST identify the 336 corresponding proxy instance from the incoming interface and perform 337 regular MLD proxy operations: it will insert/update/remove a 338 multicast forwarding state on the incoming interface, and state 339 updates will be merged into the MLD proxy membership database. An 340 aggregated Report will be sent to the upstream tunnel of the MAG when 341 the membership database (cf., section 4.1 of [RFC4605]) changes. 342 Conversely, on the reception of MLD Queries, the MAG proxy instance 343 will answer the Queries on behalf of all active downstream receivers 344 maintained in its membership database. Queries sent by the LMA do 345 not force the MAG to trigger corresponding messages immediately 346 towards MNs. Multicast traffic arriving at the MAG on an upstream 347 interface will be forwarded according to the group/source-specific 348 forwarding states as acquired for each downstream interface within 349 the MLD proxy instance. At this stage, it is important to stress 350 that IGMP/MLD proxy implementations capable of multiple instances are 351 expected to closely follow the specifications of section 4.2 in 352 [RFC4605], i.e., treat proxy instances in isolation of each other 353 while forwarding. 355 In case of a mobility handover, the MAG will continue to manage 356 upstream tunnels and downstream interfaces as foreseen in the PMIPv6 357 specification. It MUST dynamically associate new access links to 358 proxy instances that for a MN provide up-link to its corresponding 359 LMA. In addition, it MUST assure consistency of its up- and 360 downstream interfaces that change under mobility with MLD proxy 361 instances and its multicast forwarding states. The MAG will detect 362 the arrival of a new MN by receiving a router solicitation message 363 and by an upcoming link. To learn about multicast groups subscribed 364 by a newly attaching MN, the MAG sends a General Query to the MN's 365 link. Querying an upcoming interface is a standard operation of MLD 366 queriers (see Appendix A) and performed immediately after address 367 configuration. In addition, an MLD query SHOULD be initiated by the 368 proxy instance, as soon as a new interface has been configured for 369 downstream. In case, the access link between MN and MAG goes down, 370 interface-specific multicast states change. Both cases may alter the 371 composition of the membership database, which then will trigger 372 corresponding Reports towards the LMA. Note that the actual 373 observable state depends on the access link model in use. 375 An MN may be unable to answer MAG multicast membership queries due to 376 handover procedures, or its report may arrive before the MAG has 377 configured its link as proxy downstream interface. Such occurrences 378 are equivalent to a General Query loss. To prevent erroneous query 379 timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to 380 the mobility regime. In particular, MLD timers and the Robustness 381 Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant 382 with the time scale of handover operations and proxy configurations 383 in the PMIPv6 domain. 385 In proceeding this way, the MAG is entitled to aggregate multicast 386 subscriptions for each of its MLD proxy instances. However, this 387 deployment approach does not prevent multiple identical streams 388 arriving from different LMA upstream interfaces. Furthermore, a per 389 group forwarding into the wireless domain is restricted to the link 390 model in use. 392 4.3. Operations of the Local Mobility Anchor 394 For any MN, the Local Mobility Anchor acts as the persistent Home 395 Agent and at the same time as the default multicast querier for the 396 corresponding MAG. It implements the function of the designated 397 multicast router or a further MLD proxy. According to MLD reports 398 received from a MAG (on behalf of the MNs), it establishes/maintains/ 399 removes group/source-specific multicast forwarding states at its 400 corresponding downstream tunnel interfaces. At the same time, it 401 procures for aggregated multicast membership maintenance at its 402 upstream interface. Based on the multicast-transparent operations of 403 the MAGs, the LMA experiences its tunnel interfaces as multicast 404 enabled downstream links, serving zero to many listening nodes. 405 Multicast traffic arriving at the LMA is transparently forwarded 406 according to its multicast forwarding information base. 408 On the occurrence of a mobility handover, the LMA will receive 409 Binding Lifetime De-Registrations and Binding Lifetime Extensions 410 that will cause a re-mapping of home network prefixes to Proxy-CoAs 411 in its Binding Cache (see section 5.3 of [RFC5213]). The multicast 412 forwarding states require updating, as well, if the MN within an MLD 413 proxy domain is the only receiver of a multicast group. Two cases 414 need distinction: 416 1. The mobile node is the only receiver of a group behind the 417 interface at which a De-Registration was received: The membership 418 database of the MAG changes, which will trigger a Report/Done 419 sent via the MAG-to-LMA interface to remove this group. The LMA 420 thus terminates multicast forwarding. 422 2. The mobile node is the only receiver of a group behind the 423 interface at which a Lifetime Extension was received: The 424 membership database of the MAG changes, which will trigger a 425 Report sent via the MAG-to-LMA interface to add this group. The 426 LMA thus starts multicast distribution. 428 In proceeding this way, each LMA will provide transparent multicast 429 support for the group of MNs it serves. It will perform traffic 430 aggregation at the MN-group level and will assure that multicast data 431 streams are uniquely forwarded per individual LMA-to-MAG tunnel. 433 4.4. IPv4 Support 435 An MN in a PMIPv6 domain may use an IPv4 address transparently for 436 communication as specified in [I-D.ietf-netlmm-pmip6-ipv4-support]. 437 For this purpose, LMAs can register IPv4-Proxy-CoAs in its Binding 438 Caches and MAGs can provide IPv4 support in access networks. 439 Correspondingly, multicast membership management will be performed by 440 the MN using IGMP. For multicast support on the network side, an 441 IGMP proxy function needs to be deployed at MAGs in exactly the same 442 way as for IPv6. [RFC4605] defines IGMP proxy behaviour in full 443 agreement with IPv6/MLD. Thus IPv4 support can be transparently 444 provided following the obvious deployment analogy. 446 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 447 SHOULD choose multicast signaling according to address configurations 448 on the link, but MAY submit IGMP and MLD queries in parallel, if 449 needed. It should further be noted that the infrastructure cannot 450 identify two data streams as identical when distributed via an IPv4 451 and IPv6 multicast group. Thus duplicate data may be forwarded on a 452 heterogeneous network layer. 454 4.5. Multicast Availability throughout the Access Network 456 There may be deployment scenarios, where multicast services are 457 available throughout the access network independent of the PMIPv6 458 infrastructure. Direct multicast access at MAGs may be supported 459 through native multicast routing, within a flat access network that 460 includes a multicast router, via dedicated (tunnel or VPN) links 461 between MAGs and designated multicast routers, or by deploying AMT 462 [I-D.ietf-mboned-auto-multicast]. 464 Multicast deployment can be simplified in these scenarios. A single 465 proxy instance at MAGs with up-link into the multicast cloud, for 466 instance, could serve group communication purposes. MAGs could 467 operate as general multicast routers or AMT gateways, as well. 469 These solutions have in common that mobility management is covered by 470 the dynamics of multicast routing, as initially foreseen in the 471 Remote Subscription approach sketched in [RFC3775]. Care must be 472 taken to avoid service disruptions due to tardy multicast routing 473 operations [I-D.irtf-mobopts-mmcastv6-ps], and the different possible 474 approaches should be carefully investigated. Such work is beyond the 475 scope of this document. 477 4.6. A Note on Explicit Tracking 479 IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with 480 explicit tracking, which allows routers to monitor each multicast 481 receiver. This mechanism is not standardized yet, but widely 482 implemented by vendors as it supports faster leave latencies and 483 reduced signaling. 485 Enabling explicit tracking on downstream interfaces of the LMA and 486 MAG would track a single MAG and MN respectively per interface. It 487 may be used to preserve bandwidth on the MAG-MN link. 489 5. Message Source and Destination Address 491 This section describes source and destination addresses of MLD 492 messages. The interface identifier A-B denotes an interface on node 493 A, which is connected to node B. This includes tunnel interfaces. 495 5.1. Query 496 +===========+================+======================+==========+ 497 | Interface | Source Address | Destination Address | Header | 498 +===========+================+======================+==========+ 499 | | LMAA | Proxy-CoA | outer | 500 + LMA-MAG +----------------+----------------------+----------+ 501 | | LMA-link-local | [RFC2710], [RFC3810] | inner | 502 +-----------+----------------+----------------------+----------+ 503 | MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- | 504 +-----------+----------------+----------------------+----------+ 506 5.2. Report/Done 507 +===========+================+======================+==========+ 508 | Interface | Source Address | Destination Address | Header | 509 +===========+================+======================+==========+ 510 | MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- | 511 +-----------+----------------+----------------------+----------+ 512 | | Proxy-CoA | LMAA | outer | 513 + MAG-LMA +----------------+----------------------+----------+ 514 | | MAG-link-local | [RFC2710], [RFC3810] | inner | 515 +-----------+----------------+----------------------+----------+ 517 6. IANA Considerations 519 This document makes no request of IANA. 521 Note to RFC Editor: this section may be removed on publication as an 522 RFC. 524 7. Security Considerations 526 This draft does neither introduce additional messages nor novel 527 protocol operations. Consequently, no new threats arrive from 528 procedures described in this document in excess to [RFC3810], 529 [RFC4605] and [RFC5213] security concerns. 531 8. Acknowledgements 533 This memo is the outcome of extensive previous discussions and a 534 follow-up of several initial drafts on the subject. The authors 535 would like to thank (in alphabetical order) Luis Contreras, Gorry 536 Fairhurst, Seil Jeon, Jouni Korhonen, Sebastian Meiling, Liu Hui, 537 Imed Romdhani, Behcet Sarikaya, Stig Venaas, and Juan Carlos Zuniga 538 for advice, help and reviews of the document. Funding by the German 539 Federal Ministry of Education and Research within the G-LAB 540 Initiative is gratefully acknowledged. 542 9. References 544 9.1. Normative References 546 [I-D.ietf-netlmm-pmip6-ipv4-support] 547 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 548 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 549 (work in progress), September 2009. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 555 2", RFC 2236, November 1997. 557 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 558 Listener Discovery (MLD) for IPv6", RFC 2710, 559 October 1999. 561 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 562 Thyagarajan, "Internet Group Management Protocol, Version 563 3", RFC 3376, October 2002. 565 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 566 in IPv6", RFC 3775, June 2004. 568 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 569 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 571 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 572 "Internet Group Management Protocol (IGMP) / Multicast 573 Listener Discovery (MLD)-Based Multicast Forwarding 574 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 576 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 577 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 579 9.2. Informative References 581 [I-D.deng-multimob-pmip6-requirement] 582 Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, 583 "Multicast Support Requirements for Proxy Mobile IPv6", 584 draft-deng-multimob-pmip6-requirement-02 (work in 585 progress), July 2009. 587 [I-D.ietf-mboned-auto-multicast] 588 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 589 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 590 (AMT)", draft-ietf-mboned-auto-multicast-09 (work in 591 progress), June 2008. 593 [I-D.irtf-mobopts-mmcastv6-ps] 594 Fairhurst, G., Schmidt, T., and M. Waehlisch, "Multicast 595 Mobility in MIPv6: Problem Statement and Brief Survey", 596 draft-irtf-mobopts-mmcastv6-ps-09 (work in progress), 597 October 2009. 599 [I-D.zuniga-multimob-smspmip] 600 Zuniga, J., Lu, G., and A. Rahman, "Support Multicast 601 Services Using Proxy Mobile IPv6", 602 draft-zuniga-multimob-smspmip-01 (work in progress), 603 January 2010. 605 Appendix A. Initial MLD Queries on Upcoming Links 607 According to [RFC3810] and [RFC2710] when an IGMP/MLD-enabled 608 multicast router starts operating on a subnet, by default it 609 considers itself as Querier and sends several General Queries. Such 610 initial query should be sent by the router immediately, but could be 611 delayed by a (tunable) Startup Query Interval (see Sections 7.6.2. 612 and 9.6. of [RFC3810]). 614 Experimental tests on Linux and Cisco systems have revealed immediate 615 IGMP Queries following a link trigger event (within a fraction of 1 616 ms), while MLD Queries immediately followed the autoconfiguration of 617 IPv6 link-local addresses at the corresponding interface. 619 Appendix B. State of IGMP/MLD Proxy Implementations 621 The deployment scenario defined in this document requires certain 622 proxy functionalities at the MAGs that implementations of [RFC4605] 623 need to contribute. In particular, a simultaneous support of IGMP 624 and MLD is needed, as well as a configurable list of downstream 625 interfaces that may be altered during runtime, and the deployment of 626 multiple proxy instances at a single router that can operate 627 independently on separated interfaces. 629 A brief experimental trial undertaken in February 2010 revealed the 630 following divergent status of selected IGMP/MLD proxy 631 implementations. 633 Cisco Edge Router Software-based commodity edge routers (test device 634 from the 26xx-Series) implement IGMPv2/v3 proxy functions only in 635 combination with PIM-SM. There is no support of MLD Proxy. 636 Interfaces are dynamically configurable at runtime via the CLI, 637 but multiple proxy instances are not supported. 639 Linux igmpproxy IGMPv2 Proxy implementation that permits a static 640 configuration of downstream interfaces (simple bug fix required). 641 Multiple instances are prevented by a lock (corresponding code re- 642 used from a previous DVMRP implementation). IPv6/MLD is 643 unsupported. Project page: 644 http://sourceforge.net/projects/igmpproxy/. 646 Linux gproxy IGMPv3 Proxy implementation that permits configuration 647 of the upstream interface, only. Downstream interfaces are 648 collected at startup without dynamic extension of this list. No 649 support of multiple instances or MLD. Project page: http:// 650 potiron.loria.fr/projects/madynes/internals/perso/lahmadi/ 651 igmpv3proxy/. 653 Linux ecmh MLDv1/2 Proxy implementation without IGMP support that 654 inspects IPv4 tunnels and detects entcapsulated MLD messages. 655 Allows for dynamic addition of interfaces at runtime and multiple 656 instances. However, downstream interfaces cannot be configured. 657 Project page: http://sourceforge.net/projects/ecmh/ 659 Appendix C. Comparative Evaluation of Different Approaches 661 In this section, we briefly evaluate two basic PMIP concepts for 662 multicast traffic organization at LMAs: In scenario A, multicast is 663 provided by combined unicast/multicast LMAs as described in this 664 document. Scenario B directs traffic via a dedicated multicast LMA 665 as proposed in [I-D.zuniga-multimob-smspmip], for example. 667 Both approaches do not establish native multicast distribution 668 between the LMA and MAG, but use tunneling mechanisms. In scenario 669 A, a MAG is connected to different multicast-enabled LMAs, and can 670 receive the same multicast stream via multiple paths depending on the 671 group subscriptions of MNs and their associated LMAs. This problem, 672 a.k.a. tunnel convergence problem, may lead to redundant traffic at 673 the MAGs. Scenario B in contrast configures MAGs to establish a 674 tunnel to a single, dedicated multicast LMA for all attached MNs and 675 relocates overhead costs to the multicast anchor. This eliminates 676 redundant traffic, but may result in an avalanche problem at the LMA. 678 We quantify the costs of both approaches based on two metrics: The 679 amount of redundant traffic at MAGs and the number of simultaneous 680 streams at LMAs. Realistic values depend on the topology and the 681 group subscription model. To explore scalability in a large PMIP 682 domain of 1,000,000 MNs, we consider the following two extremal 683 multicast settings. 685 1. All MNs participate in distinct multicast groups. 687 2. All MNs join the same multicast groups. 689 A typical PMIP deployment approximately allows for 5,000 MNs attached 690 to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000 691 MNs require approx. 200 MAGs backed by 4 LMAs for unicast 692 transmission. In scenario A, these LMAs also forward multicast 693 streams, while in scenario B one additional dedicated LMA (LMA-M) 694 serves multicast. In the following, we calculate the metrics 695 described above. 697 Setting 1: 698 +===================+================+===================+ 699 | PMIP multicast | # of redundant | # of sim. streams | 700 | scheme | streams at MAG | at LMA / LMA-M | 701 +===================+================+===================+ 702 | Combined Unicast/ | 0 | 250,000 | 703 | Multicast LMA | | | 704 +-------------------+----------------+-------------------+ 705 | Dedicated | 0 | 1,000,000 | 706 | Multicast LMA | | | 707 +-------------------+----------------+-------------------+ 709 1,000,000 MNs are subscribed to distinct multicast groups 711 Setting 2: 712 +===================+================+===================+ 713 | PMIP multicast | # of redundant | # of sim. streams | 714 | scheme | streams at MAG | at LMA / LMA-M | 715 +===================+================+===================+ 716 | Combined Unicast/ | 4 | 50 | 717 | Multicast LMA | | | 718 +-------------------+----------------+-------------------+ 719 | Dedicated | 0 | 200 | 720 | Multicast LMA | | | 721 +-------------------+----------------+-------------------+ 723 1,000,000 MNs are subscribed to the same multicast group 725 These considerations of extremal settings show that tunnel 726 convergence, i.e., duplicate data arriving at a MAG, does cause much 727 smaller problems in scalability than the stream replication at LMAs. 729 For scenario A it should be also noted that the high stream 730 replication requirements at LMAs in setting 1 can be attenuated by 731 deploying additional LMAs in a PMIP domain, while scenario B does not 732 allow for distributing the LMA-M, as no handover management is 733 available at LMA-M. 735 Appendix D. Change Log 737 The following changes have been made from 738 draft-schmidt-multimob-pmipv6-mcast-deployment-03. 740 1. Detailed outline of multicast reconfiguration steps on handovers 741 added in protocol overview (section 3). 743 2. Clarified the details of proxy operations at the MAG along with 744 the expected features of IGMP/MLD Proxy implementations (section 745 4.2). 747 3. Clarified querying in dual-stack scenarios (section 4.4). 749 4. Subsection added on the special case, where multicast is 750 available throughout the access network (section 4.5). 752 5. Appendix on IGMP/MLD behaviour added with test reports on current 753 Proxy implementations. 755 The following changes have been made from 756 draft-schmidt-multimob-pmipv6-mcast-deployment-02. 758 1. Many editorial improvements, in particular as response to draft 759 reviews. 761 2. Section on IPv4 support added. 763 3. Added clarifications on initial IGMP/MLD Queries and 764 supplementary information in appendix. 766 4. Appendix added an comparative performance evaluation regarding 767 mixed/dedicated deployment of multicast at LMAs. 769 Authors' Addresses 771 Thomas C. Schmidt 772 HAW Hamburg 773 Berliner Tor 7 774 Hamburg 20099 775 Germany 777 Email: schmidt@informatik.haw-hamburg.de 778 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 780 Matthias Waehlisch 781 link-lab & FU Berlin 782 Hoenower Str. 35 783 Berlin 10318 784 Germany 786 Email: mw@link-lab.net 788 Suresh Krishnan 789 Ericsson 790 8400 Decarie Blvd. 791 Town of Mount Royal, QC 792 Canada 794 Email: suresh.krishnan@ericsson.com