idnits 2.17.1 draft-ietf-multimob-pmipv6-base-solution-07.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: MLD/IGMP signaling between MNs and the MAG is on point-to-point links (identical to unicast). Aggregated MLD/IGMP signaling between the MAG proxy instance and the LMA remains link-local between the routers and independent of any individual MN. So the MAG-proxy and the LMA SHOULD not use GRE key identifiers, but plain GRE encapsulation to exchange MLD queries and reports. Similarly, multicast traffic sent from an LMA to MAGs proceeds as router-to-router forwarding according to the multicast forwarding information base (MFIB) of the LMA and independent of MN's unicast addresses, while the MAG proxy instance distributes multicast data down the point-to-point links (interfaces) according to its own MFIB, independent of MN's IP addresses. -- The document date (December 29, 2010) is 4839 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-10 Summary: 1 error (**), 0 flaws (~~), 3 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: July 2, 2011 link-lab & FU Berlin 6 S. Krishnan 7 Ericsson 8 December 29, 2010 10 Base Deployment for Multicast Listener Support in PMIPv6 Domains 11 draft-ietf-multimob-pmipv6-base-solution-07 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, Local Mobility Anchors of Proxy Mobile IPv6 serve as 19 multicast subscription anchor points, while Mobile Access Gateways 20 provide MLD proxy functions. In this scenario, Mobile Nodes remain 21 agnostic of multicast mobility operations. A support for mobile 22 multicast senders is outside the scope of this document. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 2, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8 68 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8 69 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10 70 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 72 4.6. Multicast Availability throughout the Access Network . . . 12 73 4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12 74 5. Message Source and Destination Address . . . . . . . . . . . . 13 75 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15 84 Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16 85 Appendix C. Comparative Evaluation of Different Approaches . . . 17 86 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 92 [RFC3775] by network-based management functions that enable IP 93 mobility for a host without requiring its participation in any 94 mobility-related signaling. Additional network entities called the 95 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 96 responsible for managing IP mobility on behalf of the mobile node 97 (MN). 99 With these entities in place, the mobile node experiences an 100 exceptional access topology towards the static Internet in the sense 101 that the MAG introduces a routing hop also in situations, were the 102 LMA architecturally acts as the next hop (or designated) router for 103 the MN. In the particular case of multicast communication, group 104 membership management as signaled by the Multicast Listener Discovery 105 protocol (MLD) [RFC3810], [RFC2710] requires dedicated treatment at 106 the network side. 108 Multicast routing functions need to be placed carefully within the 109 PMIPv6 domain to augment unicast transmission with group 110 communication services. [RFC5213] does not explicitly address 111 multicast communication. Bi-directional home tunneling, the minimal 112 multicast support arranged by MIPv6, cannot be directly transferred 113 to network-based management scenarios, since a mobility-unaware node 114 will not initiate such a tunnel after movement. Consequently, even a 115 minimal multicast listener support in PMIPv6 domains requires an 116 explicit deployment of additional functions. 118 This document describes options for deploying multicast listener 119 functions in Proxy Mobile IPv6 domains without modifying mobility and 120 multicast protocol standards. Similar to Home Agents in Mobile IPv6, 121 PMIPv6 Local Mobility Anchors serve as multicast subscription anchor 122 points, while Mobile Access Gateways provide MLD proxy functions. 123 Mobile Nodes in this scenario remain agnostic of multicast mobility 124 operations. This document does not address specific optimizations 125 and efficiency improvements of multicast routing for network-based 126 mobility discussed in [RFC5757], as such solutions would require 127 changes to the base PMIPv6 protocol [RFC5213]. A support for mobile 128 multicast senders is outside the scope of this document, as well. 130 2. Terminology 132 This document uses the terminology as defined for the mobility 133 protocols [RFC3775], [RFC5213] and [RFC5844], as well as the 134 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 136 3. Overview 138 The reference scenario for multicast deployment in Proxy Mobile IPv6 139 domains is illustrated in Figure 1. 140 +-------------+ 141 | Content | 142 | Source | 143 +-------------+ 144 | 145 *** *** *** *** 146 * ** ** ** * 147 * * 148 * Fixed Internet * 149 * * 150 * ** ** ** * 151 *** *** *** *** 152 / \ 153 +----+ +----+ 154 |LMA1| |LMA2| Multicast Anchor 155 +----+ +----+ 156 LMAA1 | | LMAA2 157 | | 158 \\ //\\ 159 \\ // \\ 160 \\ // \\ Unicast Tunnel 161 \\ // \\ 162 \\ // \\ 163 \\ // \\ 164 Proxy-CoA1 || || Proxy-CoA2 165 +----+ +----+ 166 |MAG1| |MAG2| MLD Proxy 167 +----+ +----+ 168 | | | 169 MN-HNP1 | | MN-HNP2 | MN-HNP3 170 MN1 MN2 MN3 172 Figure 1: Reference Network for Multicast Deployment in PMIPv6 174 An MN in a PMIPv6 domain will decide on multicast group membership 175 management completely independent of its current mobility conditions. 176 It will submit MLD Report and Done messages, based on application 177 triggers, using its link-local source address and multicast 178 destination addresses according to [RFC3810], or [RFC2710]. These 179 link-local signaling messages will arrive at the currently active MAG 180 via one of its downstream local (wireless) links. A multicast 181 unaware MAG would simply discard these MLD messages. 183 To facilitate multicast in a PMIPv6 domain, an MLD proxy function 185 [RFC4605] needs to be deployed on the MAG that selects the tunnel 186 interface corresponding to the MN's LMA for its upstream interface 187 (cf., section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel 188 interface defines an MLD proxy domain at the MAG, and it contains all 189 downstream links to MNs that share this specific LMA. According to 190 standard proxy operations, MLD Report messages will be aggregated and 191 then forwarded up the tunnel interface to its corresponding LMA. 193 Serving as the designated multicast router or an additional MLD 194 proxy, the LMA will transpose any MLD message from a MAG into the 195 multicast routing infrastructure. Correspondingly, the LMA will 196 create appropriate multicast forwarding states at its tunnel 197 interface. Traffic of the subscribed groups will arrive at the LMA, 198 and the LMA will forward this traffic according to its group/source 199 states. In addition, the LMA will act as an MLD querier, seeing its 200 downstream tunnel interfaces as multicast enabled links. 202 At the MAG, MLD queries and multicast data will arrive on the 203 (tunnel) interface that is assigned to a group of access links as 204 identified by its Binding Update List (cf., section 6.1 of 205 [RFC5213]). As specified for MLD proxies, the MAG will forward 206 multicast traffic and initiate related signaling down the appropriate 207 access links to the MNs. Hence all multicast-related signaling and 208 the data traffic will transparently flow from the LMA to the MN on an 209 LMA-specific tree, which is shared among the multicast sources. 211 In case of a handover, the MN (unaware of IP mobility) will not send 212 unsolicited MLD reports. Instead, the MAG is required to maintain 213 group memberships in the following way. On observing a new MN on a 214 downstream access link, the MAG sends a General MLD Query. Based on 215 its outcome and the multicast group states previously maintained at 216 the MAG, a corresponding Report will be sent to the LMA aggregating 217 group membership states according to the proxy function. Additional 218 Reports can be omitted when the previously established multicast 219 forwarding states at the new MAG already cover the subscriptions of 220 the MN. 222 In summary, the following steps are executed on handover: 224 1. The MAG-MN link comes up and the MAG discovers the new MN. 226 2. Unicast address configuration and PMIPv6 binding are performed 227 after the MAG determines the corresponding LMA. 229 3. Following IPv6 address configuration, the MAG SHOULD send an 230 (early) MLD General Query to the new downstream link as part of 231 its standard multicast-enabled router operations. 233 4. The MAG SHOULD determine whether the MN is admissible to 234 multicast services, and stop here otherwise. 236 5. The MAG adds the new downstream link to the MLD proxy instance 237 with up-link to the corresponding LMA. 239 6. The corresponding Proxy instance triggers an MLD General Query on 240 the new downstream link. 242 7. The MN Membership Reports arrive at the MAG, either in response 243 to the early Query or to that of the Proxy instance. 245 8. The Proxy processes the MLD Report, updates states and reports 246 upstream if necessary. 248 After Re-Binding, the LMA is not required to issue a General MLD 249 Query on the tunnel link to refresh forwarding states. Multicast 250 state updates SHOULD be triggered by the MAG, which aggregates 251 subscriptions of all its MNs (see the call flow in Figure 2). 253 MN1 MAG1 MN2 MAG2 LMA 254 | | | | | 255 | Join(G) | | | | 256 +--------------->| | | | 257 | | Join(G) | | | 258 | |<---------------+ | | 259 | | | | | 260 | | Aggregated Join(G) | | 261 | +================================================>| 262 | | | | | 263 | | Mcast Data | | | 264 | |<================================================+ 265 | | | | | 266 | Mcast Data | Mcast Data | | | 267 |<---------------+--------------->| | | 268 | | | | | 269 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 270 | | | | | 271 | | |--- Rtr Sol -->| | 272 | | |<-- Rtr Adv ---| | 273 | | | | | 274 | | | MLD Query | | 275 | | |<--------------+ | 276 | | | | | 277 | | | Join(G) | | 278 | | +-------------->| | 279 | | | Aggregated Join(G) 280 | | | +===============>| 281 | | | | | 282 | | Mcast Data | | | 283 | |<================================================+ 284 | | | | Mcast Data | 285 | | | |<===============+ 286 | Mcast Data | | | | 287 |<---------------+ | Mcast Data | | 288 | | |<--------------+ | 289 | | | | | 291 Figure 2: Call Flow of Multicast-enabled PMIP with "MLD Membership 292 Report" abbreviated by "Join" 294 These multicast deployment considerations likewise apply for mobile 295 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 296 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 297 Such mobile nodes will use IGMP [RFC2236],[RFC3376] signaling for 298 multicast, which is handled by an IGMP proxy function at the MAG in 299 an analogous way. 301 Following these deployment steps, multicast management transparently 302 inter-operates with PMIPv6. It is worth noting that MNs - while 303 being attached to the same MAG, but associated with different LMAs - 304 can subscribe to the same multicast group. Thereby data could be 305 distributed redundantly in the network and duplicate traffic could 306 arrive at a MAG. Additionally in a point-to-point wireless link 307 model, a MAG might be forced to transmit the same data over one 308 wireless domain to different MNs. However, multicast traffic 309 arriving at one interface of the MN will always remain unique, i.e., 310 the mobile multicast distribution system will never cause duplicate 311 packets arriving at an MN (see Appendix C for further 312 considerations). 314 4. Deployment Details 316 Multicast activation in a PMIPv6 domain requires to deploy general 317 multicast functions at PMIPv6 routers and to define their interaction 318 with the PMIPv6 protocol in the following way: 320 4.1. Operations of the Mobile Node 322 A Mobile Node willing to manage multicast traffic will join, maintain 323 and leave groups as if located in the fixed Internet. No specific 324 mobility actions nor implementations are required at the MN. 326 4.2. Operations of the Mobile Access Gateway 328 A Mobile Access Gateway is required to assist in MLD signaling and 329 data forwarding between the MNs which it serves, and the 330 corresponding LMAs associated to each MN. It therefore needs to 331 implement an instance of the MLD proxy function [RFC4605] for each 332 upstream tunnel interface that has been established with an LMA. The 333 MAG decides on the mapping of downstream links to a proxy instance 334 (and hence an upstream link to an LMA) based on the regular Binding 335 Update List as maintained by PMIPv6 standard operations (cf., section 336 6.1 of [RFC5213]). As links connecting MNs and MAGs change under 337 mobility, MLD proxies at MAGs MUST be able to dynamically add and 338 remove downstream interfaces in its configuration. 340 On the reception of MLD reports from an MN, the MAG MUST identify the 341 corresponding proxy instance from the incoming interface and perform 342 regular MLD proxy operations: it will insert/update/remove multicast 343 forwarding state on the incoming interface, and will merge state 344 updates into the MLD proxy membership database. It will then send an 345 aggregated Report via the upstream tunnel to the LMA when the 346 membership database (cf., section 4.1 of [RFC4605]) changes. 347 Conversely, on the reception of MLD Queries, the MAG proxy instance 348 will answer the Queries on behalf of all active downstream receivers 349 maintained in its membership database. Queries sent by the LMA do 350 not force the MAG to trigger corresponding messages immediately 351 towards MNs. Multicast traffic arriving at the MAG on an upstream 352 interface will be forwarded according to the group/source-specific 353 forwarding states as acquired for each downstream interface within 354 the MLD proxy instance. At this stage, it is important to note that 355 IGMP/MLD proxy implementations capable of multiple instances are 356 expected to closely follow the specifications of section 4.2 in 357 [RFC4605], i.e., treat proxy instances in isolation of each other 358 while forwarding. In providing isolated proxy instances, the MAG 359 will uniquely serve its downstream links with exactly the data that 360 belong to whatever group is subscribed on the particular interface. 362 After a handover, the MAG will continue to manage upstream tunnels 363 and downstream interfaces as specified in the PMIPv6 specification. 364 It MUST dynamically associate new access links to proxy instances 365 that include the upstream connection to the corresponding LMA. The 366 MAG detects the arrival of a new MN by receiving a router 367 solicitation message and by an upcoming link. To learn about 368 multicast groups subscribed by a newly attaching MN, the MAG SHOULD 369 send a General Query to the MN's link. Querying an upcoming 370 interface is a standard operation of MLD queriers (see Appendix A) 371 and is performed immediately after address configuration. In 372 addition, an MLD query SHOULD be initiated by the proxy instance, as 373 soon as a new interface has been configured for downstream. In case, 374 the access link between MN and MAG goes down, interface-specific 375 multicast states change. Both cases may alter the composition of the 376 membership database and this will trigger corresponding Reports 377 towards the LMA. Note that the actual observable state depends on 378 the access link model in use. 380 An MN may be unable to answer MAG multicast membership queries due to 381 handover procedures, or its report may arrive before the MAG has 382 configured its link as proxy downstream interface. Such occurrences 383 are equivalent to a General Query loss. To prevent erroneous query 384 timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to 385 the mobility regime. In particular, MLD timers and the Robustness 386 Variable (see section 9 of [RFC3810]) SHOULD be chosen to be 387 compliant with the time scale of handover operations and proxy 388 configurations in the PMIPv6 domain. 390 In proceeding this way, the MAG is able to aggregate multicast 391 subscriptions for each of its MLD proxy instances. However, this 392 deployment approach does not prevent multiple identical streams 393 arriving from different LMA upstream interfaces. Furthermore, a 394 multipoint channel forwarding into the wireless domain is prevented 395 by the point-to-point link model in use. 397 4.3. Operations of the Local Mobility Anchor 399 For any MN, the Local Mobility Anchor acts as the persistent Home 400 Agent and at the same time as the default multicast querier for the 401 corresponding MAG. It implements the function of the designated 402 multicast router or a further MLD proxy. According to MLD reports 403 received from a MAG (on behalf of the MNs), it establishes/maintains/ 404 removes group/source-specific multicast forwarding states at its 405 corresponding downstream tunnel interfaces. At the same time, it 406 procures for aggregated multicast membership maintenance at its 407 upstream interface. Based on the multicast-transparent operations of 408 the MAGs, the LMA treats its tunnel interfaces as multicast enabled 409 downstream links, serving zero to many listening nodes. Multicast 410 traffic arriving at the LMA is transparently forwarded according to 411 its multicast forwarding information base. 413 After a handover, the LMA will receive Binding De-Registrations and 414 Binding Lifetime Extensions that will cause a re-mapping of home 415 network prefix(es) to a new Proxy-CoA in its Binding Cache (see 416 section 5.3 of [RFC5213]). The multicast forwarding states require 417 updating, as well, if the MN within an MLD proxy domain is the only 418 receiver of a multicast group. Two different cases need to be 419 considered: 421 1. The mobile node is the only receiver of a group behind the 422 interface at which a De-Registration was received: The membership 423 database of the MAG changes, which will trigger a Report/Done 424 sent via the MAG-to-LMA interface to remove this group. The LMA 425 thus terminates multicast forwarding. 427 2. The mobile node is the only receiver of a group behind the 428 interface at which a Lifetime Extension was received: The 429 membership database of the MAG changes, which will trigger a 430 Report sent via the MAG-to-LMA interface to add this group. The 431 LMA thus starts multicast distribution. 433 In proceeding this way, each LMA will provide transparent multicast 434 support for the group of MNs it serves. It will perform traffic 435 aggregation at the MN-group level and will assure that multicast data 436 streams are uniquely forwarded per individual LMA-to-MAG tunnel. 438 4.4. IPv4 Support 440 An MN in a PMIPv6 domain may use an IPv4 address transparently for 441 communication as specified in [RFC5844]. For this purpose, LMAs can 442 register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide 443 IPv4 support in access networks. Correspondingly, multicast 444 membership management will be performed by the MN using IGMP. For 445 multicast support on the network side, an IGMP proxy function needs 446 to be deployed at MAGs in exactly the same way as for IPv6. 447 [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/ 448 MLD. Thus IPv4 support can be transparently provided following the 449 obvious deployment analogy. 451 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 452 SHOULD choose multicast signaling according to address configurations 453 on the link, but MAY submit IGMP and MLD queries in parallel, if 454 needed. It should further be noted that the infrastructure cannot 455 identify two data streams as identical when distributed via an IPv4 456 and IPv6 multicast group. Thus duplicate data may be forwarded on a 457 heterogeneous network layer. 459 A particular note is worth giving the scenario of [RFC5845] in which 460 overlapping private address spaces of different operators can be 461 hosted in a PMIP domain by using GRE encapsulation with key 462 identification. This scenario implies that unicast communication in 463 the MAG-LMA tunnel can be individually identified per MN by the GRE 464 keys. This scenario still does not impose any special treatment of 465 multicast communication for the following reasons. 467 MLD/IGMP signaling between MNs and the MAG is on point-to-point links 468 (identical to unicast). Aggregated MLD/IGMP signaling between the 469 MAG proxy instance and the LMA remains link-local between the routers 470 and independent of any individual MN. So the MAG-proxy and the LMA 471 SHOULD not use GRE key identifiers, but plain GRE encapsulation to 472 exchange MLD queries and reports. Similarly, multicast traffic sent 473 from an LMA to MAGs proceeds as router-to-router forwarding according 474 to the multicast forwarding information base (MFIB) of the LMA and 475 independent of MN's unicast addresses, while the MAG proxy instance 476 distributes multicast data down the point-to-point links (interfaces) 477 according to its own MFIB, independent of MN's IP addresses. 479 It remains an open issue how communication proceeds in a multi- 480 operator scenario, i.e., from which network the LMA pulls multicast 481 traffic. This could be any mobility Operator itself, or a third 482 party. However, this backbone routing in general is out of scope of 483 the document, and most likely a matter of contracts. 485 4.5. Multihoming Support 487 An MN can connect to a PMIPv6 domain through multiple interfaces and 488 experience transparent unicast handovers at all interfaces (cf., 489 section 5.4 of [RFC5213]). In such simultaneous access scenario, it 490 can autonomously assign multicast channel subscriptions to individual 491 interfaces (see [RFC5757] for additional details). While doing so, 492 multicast mobility operations described in this document will 493 transparently preserve the association of channels to interfaces in 494 the following way. 496 Multicast listener states are kept per interface in the MLD state 497 table. An MN will answer to an MLD General Query received on a 498 specific (re-attaching) interface according to the specific 499 interface's state table. Thereafter, multicast forwarding is resumed 500 for channels identical to those under subscription prior to handover. 501 Consequently, an MN in a PMIPv6 domain MAY use multiple interfaces to 502 facilitate load balancing or redundancy, but cannot follow a 'make- 503 before-break' approach to service continuation on handovers. 505 4.6. Multicast Availability throughout the Access Network 507 There may be deployment scenarios, where multicast services are 508 available throughout the access network independent of the PMIPv6 509 infrastructure. Direct multicast access at MAGs may be supported 510 through native multicast routing within a flat access network that 511 includes a multicast router, via dedicated (tunnel or VPN) links 512 between MAGs and designated multicast routers, or by deploying AMT 513 [I-D.ietf-mboned-auto-multicast]. 515 Multicast deployment can be simplified in these scenarios. A single 516 proxy instance at MAGs with up-link into the multicast cloud, for 517 instance, could serve group communication purposes. MAGs could 518 operate as general multicast routers or AMT gateways, as well. 520 Common to these solutions is that mobility management is covered by 521 the dynamics of multicast routing, as initially foreseen in the 522 Remote Subscription approach sketched in [RFC3775]. Care must be 523 taken to avoid avalanche problems or service disruptions due to tardy 524 multicast routing operations, and to adapt to different link-layer 525 technologies [RFC5757]. The different possible approaches should be 526 carefully investigated beyond the initial sketch in Appendix C. Such 527 work is beyond the scope of this document. 529 4.7. A Note on Explicit Tracking 531 An IGMPv3/MLDv2 Querier may operate in combination with explicit 532 tracking as described in Appendix 2 of [RFC3376], or Appendix 2 533 of[RFC3810]. This mechanism allows routers to monitor each multicast 534 receiver individually. Even though this procedure is not 535 standardized yet, it is widely implemented by vendors as it supports 536 faster leave latencies and reduced signaling. 538 Enabling explicit tracking on downstream interfaces of the LMA and 539 MAG would track a single MAG and MN respectively per interface. It 540 may be used to preserve bandwidth on the MAG-MN link. 542 5. Message Source and Destination Address 544 This section describes source and destination addresses of MLD 545 messages and encapsulating outer headers when deployed in the PMIPv6 546 domain. This overview is for clarification purposes, only, and does 547 not define a behavior different from referenced standards in any way. 549 The interface identifier A-B denotes an interface on node A, which is 550 connected to node B. This includes tunnel interfaces. Destination 551 addresses for MLD/IGMP messages SHALL be as specified in Section 8. 552 of [RFC2710] for MLDv1, and Section 5.1.15. and Section 5.2.14. of 553 [RFC3810] for MLDv2. 555 5.1. Query 556 +===========+================+======================+==========+ 557 | Interface | Source Address | Destination Address | Header | 558 +===========+================+======================+==========+ 559 | | LMAA | Proxy-CoA | outer | 560 + LMA-MAG +----------------+----------------------+----------+ 561 | | LMA-link-local | [RFC2710], [RFC3810] | inner | 562 +-----------+----------------+----------------------+----------+ 563 | MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- | 564 +-----------+----------------+----------------------+----------+ 566 5.2. Report/Done 567 +===========+================+======================+==========+ 568 | Interface | Source Address | Destination Address | Header | 569 +===========+================+======================+==========+ 570 | MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- | 571 +-----------+----------------+----------------------+----------+ 572 | | Proxy-CoA | LMAA | outer | 573 + MAG-LMA +----------------+----------------------+----------+ 574 | | MAG-link-local | [RFC2710], [RFC3810] | inner | 575 +-----------+----------------+----------------------+----------+ 577 6. IANA Considerations 579 This document makes no request of IANA. 581 Note to RFC Editor: this section may be removed on publication as an 582 RFC. 584 7. Security Considerations 586 This draft does not introduce additional messages or novel protocol 587 operations. Consequently, no new threats are introduced by this 588 document in addition to those identified as security concerns of 589 [RFC3810], [RFC4605], [RFC5213], and [RFC5844]. 591 However, particular attention should be paid to implications of 592 combining multicast and mobility management at network entities. As 593 this specification allows mobile nodes to initiate the creation of 594 multicast forwarding states at MAGs and LMAs while changing 595 attachments, threats of resource exhaustion at PMIP routers and 596 access networks arrive from rapid state changes, as well as from high 597 volume data streams routed into access networks of limited 598 capacities. In addition to proper authorization checks of MNs, rate 599 controls at replicators MAY be required to protect the agents and the 600 downstream networks. In particular, MLD proxy implementations at 601 MAGs SHOULD carefully procure for automatic multicast state 602 extinction on the departure of MNs, as mobile multicast listeners in 603 the PMIPv6 domain will not actively terminate group membership prior 604 to departure. 606 8. Acknowledgements 608 This memo follows initial requirements work presented in 609 draft-deng-multimob-pmip6-requirement, and is the outcome of 610 extensive previous discussions and a follow-up of several initial 611 drafts on the subject. The authors would like to thank (in 612 alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley, Gorry 613 Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Guang Lu, 614 Sebastian Meiling, Liu Hui, Akbar Rahman, Imed Romdhani, Behcet 615 Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for 616 advice, help and reviews of the document. Funding by the German 617 Federal Ministry of Education and Research within the G-LAB 618 Initiative is gratefully acknowledged. 620 9. References 622 9.1. Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, March 1997. 627 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 628 Listener Discovery (MLD) for IPv6", RFC 2710, 629 October 1999. 631 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 632 Thyagarajan, "Internet Group Management Protocol, Version 633 3", RFC 3376, October 2002. 635 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 636 in IPv6", RFC 3775, June 2004. 638 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 639 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 641 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 642 "Internet Group Management Protocol (IGMP) / Multicast 643 Listener Discovery (MLD)-Based Multicast Forwarding 644 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 646 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 647 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 649 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 650 Mobile IPv6", RFC 5844, May 2010. 652 9.2. Informative References 654 [I-D.ietf-mboned-auto-multicast] 655 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 656 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 657 (AMT)", draft-ietf-mboned-auto-multicast-10 (work in 658 progress), March 2010. 660 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 661 2", RFC 2236, November 1997. 663 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 664 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 665 and Brief Survey", RFC 5757, February 2010. 667 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 668 "Generic Routing Encapsulation (GRE) Key Option for Proxy 669 Mobile IPv6", RFC 5845, June 2010. 671 Appendix A. Initial MLD Queries on Upcoming Links 673 According to [RFC3810] and [RFC2710] when an IGMP/MLD-enabled 674 multicast router starts operating on a subnet, by default it 675 considers itself as Querier and sends several General Queries. Such 676 initial query should be sent by the router immediately, but could be 677 delayed by a (tunable) Startup Query Interval (see Sections 7.6.2. 678 and 9.6. of [RFC3810]). 680 Experimental tests on Linux and Cisco systems have revealed immediate 681 IGMP Queries following a link trigger event (within a fraction of 1 682 ms), while MLD Queries immediately followed the autoconfiguration of 683 IPv6 link-local addresses at the corresponding interface. 685 Appendix B. State of IGMP/MLD Proxy Implementations 687 The deployment scenario defined in this document requires certain 688 proxy functionalities at the MAGs that implementations of [RFC4605] 689 need to contribute. In particular, a simultaneous support of IGMP 690 and MLD is needed, as well as a configurable list of downstream 691 interfaces that may be altered during runtime, and the deployment of 692 multiple proxy instances at a single router that can operate 693 independently on separated interfaces. 695 A brief experimental trial undertaken in February 2010 revealed the 696 following divergent status of selected IGMP/MLD proxy 697 implementations. 699 Cisco Edge Router Software-based commodity edge routers (test device 700 from the 26xx-Series) implement IGMPv2/v3 proxy functions only in 701 combination with PIM-SM. There is no support of MLD Proxy. 702 Interfaces are dynamically configurable at runtime via the CLI, 703 but multiple proxy instances are not supported. 705 Linux igmpproxy IGMPv2 Proxy implementation that permits a static 706 configuration of downstream interfaces (simple bug fix required). 707 Multiple instances are prevented by a lock (corresponding code re- 708 used from a previous DVMRP implementation). IPv6/MLD is 709 unsupported. Project page: 710 http://sourceforge.net/projects/igmpproxy/. 712 Linux gproxy IGMPv3 Proxy implementation that permits configuration 713 of the upstream interface, only. Downstream interfaces are 714 collected at startup without dynamic extension of this list. No 715 support of multiple instances or MLD. Project page: http:// 716 potiron.loria.fr/projects/madynes/internals/perso/lahmadi/ 717 igmpv3proxy/. 719 Linux ecmh MLDv1/2 Proxy implementation without IGMP support that 720 inspects IPv4 tunnels and detects encapsulated MLD messages. 721 Allows for dynamic addition of interfaces at runtime and multiple 722 instances. However, downstream interfaces cannot be configured. 723 Project page: http://sourceforge.net/projects/ecmh/ 725 Appendix C. Comparative Evaluation of Different Approaches 727 In this section, we briefly evaluate two orthogonal PMIP concepts for 728 multicast traffic organization at LMAs: In scenario A, multicast is 729 provided by combined unicast/multicast LMAs as described in this 730 document. Scenario B directs traffic via a dedicated, central 731 multicast router ("LMA-M") that tunnels packets to MAGs independent 732 of unicast hand-offs. 734 Both approaches do not establish native multicast distribution 735 between the LMA and MAG, but use tunneling mechanisms. In scenario 736 A, a MAG is connected to different multicast-enabled LMAs, and can 737 receive the same multicast stream via multiple paths depending on the 738 group subscriptions of MNs and their associated LMAs. This problem, 739 a.k.a. tunnel convergence problem, may lead to redundant traffic at 740 the MAGs. Scenario B in contrast configures MAGs to establish a 741 tunnel to a single, dedicated multicast LMA for all attached MNs and 742 relocates overhead costs to the multicast anchor. This eliminates 743 redundant traffic, but may result in an avalanche problem at the LMA. 745 We quantify the costs of both approaches based on two metrics: The 746 amount of redundant traffic at MAGs and the number of simultaneous 747 streams at LMAs. Realistic values depend on the topology and the 748 group subscription model. To explore scalability in a large PMIP 749 domain of 1,000,000 MNs, we consider the following two extremal 750 multicast settings. 752 1. All MNs participate in distinct multicast groups. 754 2. All MNs join the same multicast groups. 756 A typical PMIP deployment approximately allows for 5,000 MNs attached 757 to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000 758 MNs require approx. 200 MAGs backed by 4 LMAs for unicast 759 transmission. In scenario A, these LMAs also forward multicast 760 streams, while in scenario B one additional dedicated LMA (LMA-M) 761 serves multicast. In the following, we calculate the metrics 762 described above. In addition, we display the number of packet 763 streams that cross the interconnecting (wired) network within a 764 PMIPv6 domain. 766 Setting 1: 767 +===================+==============+================+===============+ 768 | PMIP multicast | # of redund. | # of simul. | # of total | 769 | scheme | streams | streams | streams in | 770 | | at MAG | at LMA/LMA-M | the network | 771 +===================+==============+================+===============+ 772 | Combined Unicast/ | 0 | 250,000 | 1,000,000 | 773 | Multicast LMA | | | | 774 +-------------------+--------------+----------------+---------------+ 775 | Dedicated | 0 | 1,000,000 | 1,000,000 | 776 | Multicast LMA | | | | 777 +-------------------+--------------+----------------+---------------+ 779 1,000,000 MNs are subscribed to distinct multicast groups 781 Setting 2: 782 +===================+==============+================+===============+ 783 | PMIP multicast | # of redund. | # of simul. | # of total | 784 | scheme | streams | streams | streams in | 785 | | at MAG | at LMA/LMA-M | the network | 786 +===================+==============+================+===============+ 787 | Combined Unicast/ | 3 | 200 | 800 | 788 | Multicast LMA | | | | 789 +-------------------+--------------+----------------+---------------+ 790 | Dedicated | 0 | 200 | 200 | 791 | Multicast LMA | | | | 792 +-------------------+--------------+----------------+---------------+ 794 1,000,000 MNs are subscribed to the same multicast group 796 These considerations of extremal settings show that packet 797 duplication and replication effects apply in changing intensities for 798 different use cases of multicast data services. However, tunnel 799 convergence, i.e., duplicate data arriving at a MAG, does cause much 800 smaller problems in scalability than the stream replication at LMAs 801 (avalanche problem). For scenario A, it should be also noted that 802 the high stream replication requirements at LMAs in setting 1 can be 803 attenuated by deploying additional LMAs in a PMIP domain, while 804 scenario B does not allow for distributing the LMA-M, as no handover 805 management is available at LMA-M. 807 Appendix D. Change Log 809 The following changes have been made from version 810 draft-ietf-multimob-pmipv6-base-solution-05. 812 1. Clarification and section-based reference to destination 813 addresses in MLD in response to WG feedback. 815 2. Removed reference to individual draft-zuniga-multimob-smspmip in 816 Appendix C and added explanations in response to WG feedback. 818 The following changes have been made from version 819 draft-ietf-multimob-pmipv6-base-solution-04. 821 1. Clarifications and editorial improvements in response to WG 822 feedback. 824 The following changes have been made from version 825 draft-ietf-multimob-pmipv6-base-solution-03. 827 1. Clarifications and editorial improvements in response to WG 828 feedback. 830 2. Added pointers and explanations to Explicit Tracking and GRE 831 tunneling in the IPv4 scenario (RFC 5845). 833 The following changes have been made from version 834 draft-ietf-multimob-pmipv6-base-solution-02. 836 1. Clarifications and editorial improvements in response to WG 837 feedback. 839 The following changes have been made from version 840 draft-ietf-multimob-pmipv6-base-solution-01. 842 1. Editorial improvements in response to WG feedback. 844 The following changes have been made from version 845 draft-ietf-multimob-pmipv6-base-solution-00. 847 1. Added section on multihoming. 849 2. Updated security section. 851 3. Several editorial improvements and minor extensions. 853 The following changes have been made from the previous individual 854 version draft-schmidt-multimob-pmipv6-mcast-deployment-04. 856 1. Updated references. 858 2. Corrected typos. 860 3. Adjusted title & document name. 862 The following changes have been made from 863 draft-schmidt-multimob-pmipv6-mcast-deployment-03. 865 1. Detailed outline of multicast reconfiguration steps on handovers 866 added in protocol overview (section 3). 868 2. Clarified the details of proxy operations at the MAG along with 869 the expected features of IGMP/MLD Proxy implementations (section 870 4.2). 872 3. Clarified querying in dual-stack scenarios (section 4.4). 874 4. Subsection added on the special case, where multicast is 875 available throughout the access network (section 4.5). 877 5. Appendix on IGMP/MLD behaviour added with test reports on current 878 Proxy implementations. 880 The following changes have been made from 881 draft-schmidt-multimob-pmipv6-mcast-deployment-02. 883 1. Many editorial improvements, in particular as response to draft 884 reviews. 886 2. Section on IPv4 support added. 888 3. Added clarifications on initial IGMP/MLD Queries and 889 supplementary information in appendix. 891 4. Appendix added an comparative performance evaluation regarding 892 mixed/dedicated deployment of multicast at LMAs. 894 Authors' Addresses 896 Thomas C. Schmidt 897 HAW Hamburg 898 Berliner Tor 7 899 Hamburg 20099 900 Germany 902 Email: schmidt@informatik.haw-hamburg.de 903 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 904 Matthias Waehlisch 905 link-lab & FU Berlin 906 Hoenower Str. 35 907 Berlin 10318 908 Germany 910 Email: mw@link-lab.net 912 Suresh Krishnan 913 Ericsson 914 8400 Decarie Blvd. 915 Town of Mount Royal, QC 916 Canada 918 Email: suresh.krishnan@ericsson.com