RFC 6224
Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains
Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains ✨
okay so this RFC is RFC 6224, and it's all about getting multicast listeners working inside Proxy Mobile IPv6 (PMIPv6) domains 🌸 It was written by T. Schmidt (HAW Hamburg), M. Waehlisch (link-lab & FU Berlin), and S. Krishnan (Ericsson), and it came out in April 2011. It's Informational, so it's not a Standards Track spec, but it's still a Proposed-Standards-era IETF product that reflects IETF consensus and got IESG approval 🎀 The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's no earlier RFC it replaces or patches 💅
Abstract
okay so the big idea 🦋 this doc describes ways to switch on multicast listener functions in PMIPv6 domains without changing any of the existing mobility or multicast standards. Just like home agents in Mobile IPv6, the Local Mobility Anchors (LMAs) act as the anchor points for multicast subscriptions, and the Mobile Access Gateways (MAGs) run the MLD proxy functions. The best part is that the mobile nodes don't need to know any of the multicast mobility stuff is happening 🫶 Support for mobile multicast senders is out of scope here 😭
Status of This Memo
this is not an Internet Standards Track spec, it's just published for info purposes 🌈
this is a product of the IETF. it reflects consensus from the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 📚
for the current status, any errata, or how to give feedback, go to http://www.rfc-editor.org/info/rfc6224 ✨
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please actually read those, because they spell out your rights and restrictions for this doc 🙈 If you extract any Code Components from this doc, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.
⚠️ heads up: the "must" above is just my casual voice. The license terms are what the original text says, so go check the source for the exact wording.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8
4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8
4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
4.6. Multicast Availability throughout the Access Network . . . 12
4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 13
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 16
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16
Appendix C. Comparative Evaluation of Different Approaches . . . 171. Introduction 💖
okay so Proxy Mobile IPv6 (PMIPv6) [RFC5213] basically extends Mobile IPv6 (MIPv6) [RFC3775] with network-based management, which means a host gets IP mobility without having to take part in any mobility signaling itself 🧚 The network does the work through two new entities: the Local Mobility Anchor (LMA) and the Mobile Access Gateways (MAGs), and they handle IP mobility on behalf of the mobile node (MN) 💅
here's the tricky bit ✨ from the MN's point of view, its access topology looks kinda weird compared to the static Internet. The MAG adds a routing hop, even though architecturally the LMA is the one acting as the next hop (or designated) router for the MN 🙈 For multicast, the group membership stuff gets signaled through the Multicast Listener Discovery (MLD) protocol [RFC3810] [RFC2710], and that needs special handling on the network side 😭
multicast routing has to be placed carefully inside the PMIPv6 domain so that group communication can sit on top of unicast transmission 🔥 [RFC5213] doesn't explicitly cover multicast at all. MIPv6's minimal multicast support uses bidirectional home tunneling, but that can't just be moved over to network-based mobility, because a mobility-unaware node won't start such a tunnel after it moves 💀 So even minimal multicast listener support in PMIPv6 domains needs some extra functions to be deployed on purpose.
this document describes options for deploying those multicast listener functions in PMIPv6 domains without modifying the mobility and multicast protocol standards 🦋 Like home agents in MIPv6, the PMIPv6 LMAs serve as multicast subscription anchor points, and the MAGs provide MLD proxy functions. The mobile nodes stay totally agnostic about multicast mobility operations 🌸 It doesn't go into specific optimizations or efficiency improvements for multicast routing under network-based mobility, which are discussed in [RFC5757], because those solutions would require changes to the base PMIPv6 protocol [RFC5213] 👑 And again, support for mobile multicast senders is also outside this doc's scope 🎀
2. Terminology 🌈
this doc uses the terminology defined for the mobility protocols [RFC3775], [RFC5213], and [RFC5844], as well as the multicast edge-related protocols [RFC3376], [RFC3810], and [RFC4605] 📚
3. Overview ✨
okay so the big picture, bestie 🗺️ PMIPv6 multicast deployment has a reference setup, and it looks like this. LMAA and MN-HNP are the LMA Address and Mobile Node's Home Network Prefix (defined in [RFC5213], so go check there if you want the deets 🤓).
+-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/ \
+----+ +----+
|LMA1| |LMA2| Multicast Anchor
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3Figure 1: Reference Network for Multicast Deployment in PMIPv6
An MN in a PMIPv6 domain will decide on multicast group membership management completely independent of its current mobility conditions. 💅 It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses according to [RFC3810] or [RFC2710]. These link-local signaling messages will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast-unaware MAG would simply discard these MLD messages. 🙈
To facilitate multicast in a PMIPv6 domain, an MLD proxy function [RFC4605] needs to be deployed on the MAG that selects the tunnel interface corresponding to the MN's LMA for its upstream interface (cf., Section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel interface defines an MLD proxy domain at the MAG, and it contains all downstream links to MNs that share this specific LMA. According to standard proxy operations, MLD Report messages will be aggregated and then forwarded up the tunnel interface to the MN's corresponding LMA. 🫶
Serving as the designated multicast router or an additional MLD proxy, the LMA will transpose any MLD message from a MAG into the multicast routing infrastructure. Correspondingly, the LMA will create appropriate multicast forwarding states at its tunnel interface. Traffic of the subscribed groups will arrive at the LMA, and the LMA will forward this traffic according to its group/source states. In addition, the LMA will act as an MLD querier, seeing its downstream tunnel interfaces as multicast-enabled links. 👑
At the MAG, MLD queries and multicast data will arrive on the (tunnel) interface that is assigned to a group of access links as identified by its Binding Update List (cf., Section 6.1 of [RFC5213]). As specified for MLD proxies, the MAG will forward multicast traffic and initiate related signaling down the appropriate access links to the MNs. Hence, all multicast-related signaling and the data traffic will transparently flow from the LMA to the MN on an LMA-specific tree, which is shared among the multicast sources. 🌸
In case of a handover, the MN (unaware of IP mobility) will not send unsolicited MLD reports. Instead, the MAG is required to maintain group memberships in the following way. On observing a new MN on a downstream access link, the MAG sends a MLD General Query. Based on its outcome and the multicast group states previously maintained at the MAG, a corresponding Report will be sent to the LMA aggregating group membership states according to the proxy function. Additional Reports can be omitted when the previously established multicast forwarding states at the new MAG already cover the subscriptions of the MN. ✨
In summary, the following steps are executed on handover:
- The MAG-MN link comes up and the MAG discovers the new MN.
- Unicast address configuration and PMIPv6 binding are performed after the MAG determines the corresponding LMA.
- Following IPv6 address configuration, the MAG should send an (early) MLD General Query to the new downstream link as part of its standard multicast-enabled router operations.
- The MAG should determine whether the MN is admissible to multicast services; if it's not, then stop here.
- The MAG adds the new downstream link to the MLD proxy instance with up-link to the corresponding LMA.
- The corresponding proxy instance triggers an MLD General Query on the new downstream link.
- The MN Membership Reports arrive at the MAG, in response either to the early query or to the query sent by the proxy instance.
- The Proxy processes the MLD Report, updates states, and reports upstream if necessary.
After Re-Binding, the LMA is not required to issue a MLD General Query on the tunnel link to refresh forwarding states. 🦋 Multicast state updates should be triggered by the MAG, which aggregates subscriptions of all its MNs (see the call flow in Figure 2).
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |Figure 2: Call Flow of Multicast-Enabled PMIP with "MLD Membership Report" Abbreviated by "Join"
These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. PMIPv6 can provide IPv4 home address mobility support [RFC5844]. Such mobile nodes will use IGMP [RFC2236] [RFC3376] signaling for multicast, which is handled by an IGMP proxy function at the MAG in an analogous way. 🧚
Following these deployment steps, multicast management transparently interoperates with PMIPv6. It is worth noting that MNs -- while being attached to the same MAG, but associated with different LMAs -- can subscribe to the same multicast group. Thereby, data could be distributed redundantly in the network and duplicate traffic could arrive at a MAG. Additionally, in a point-to-point wireless link model, a MAG might be forced to transmit the same data over one wireless domain to different MNs. However, multicast traffic arriving at one interface of the MN will always remain unique, i.e., the mobile multicast distribution system will never cause duplicate packets arriving at an MN (see Appendix C for further considerations). 💖
4. Deployment Details 🎀
Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define their interaction with the PMIPv6 protocol in the following way.
4.1. Operations of the Mobile Node
A mobile node willing to manage multicast traffic will join, maintain, and leave groups as if located in the fixed Internet. No specific mobility actions nor implementations are required at the MN. 🌈
4.2. Operations of the Mobile Access Gateway ✨
okay so the Mobile Access Gateway is required to assist in MLD signaling and data forwarding between the MNs it serves and the corresponding LMAs tied to each MN 💅. It therefore needs to run an instance of the MLD proxy function [RFC4605] for each upstream tunnel interface that has been set up with an LMA. The MAG decides how downstream links map to a proxy instance (and therefore an upstream link to an LMA) using the regular Binding Update List, which PMIPv6 standard operations keep up to date (cf., Section 6.1 of [RFC5213]). Since the links between MNs and MAGs keep changing as the MNs move around, MLD proxies at MAGs must be able to dynamically add and remove downstream interfaces in their configurations 🦋.
When MLD reports come in from an MN, the MAG has to figure out which proxy instance matches the incoming interface and then run regular MLD proxy operations 🎀. It inserts, updates, or removes multicast forwarding state on that incoming interface, and merges those state updates into the MLD proxy membership database. Then it sends an aggregated Report up the tunnel to the LMA whenever the membership database changes (cf., Section 4.1 of [RFC4605]). Flip it around and when MLD queries show up, the MAG proxy instance answers them on behalf of every active downstream receiver in its membership database 🧚. Queries sent by the LMA do not force the MAG to trigger corresponding messages right away toward MNs. Multicast traffic that arrives at the MAG on an upstream interface gets forwarded based on the group-specific or source-specific forwarding states acquired for each downstream interface inside the MLD proxy instance 💜. Also, it's important to note that IGMP/MLD proxy implementations capable of multiple instances are expected to closely follow the specifications of Section 4.2 in [RFC4605], meaning they treat proxy instances in isolation from each other while forwarding 🫶. By keeping the proxy instances isolated, the MAG makes sure each downstream link gets exactly the data for whatever group is subscribed on that particular interface. Iconic, honestly 👑.
After a handover, the MAG keeps managing upstream tunnels and downstream interfaces the way the PMIPv6 specification says 🌸. It must dynamically associate new access links with proxy instances that include the upstream connection to the corresponding LMA. The MAG notices a new MN has arrived when it receives a router solicitation message and when there's an upcoming link. To find out which multicast groups a newly attaching MN is subscribed to, the MAG should send a General Query to the MN's link. Querying an upcoming interface is a standard MLD querier operation (see Appendix A), and it happens right after address configuration. On top of that, an MLD query should be initiated by the proxy instance as soon as a new interface has been configured for downstream. If the access link between the MN and the MAG goes down, the interface-specific multicast states change. Both of these situations can change the makeup of the membership database, and that triggers corresponding Reports toward the LMA. Just note that the actual observable state depends on the access link model in use 🙈.
An MN might not be able to answer MAG multicast membership queries because of handover procedures, or its report might show up before the MAG has configured its link as the proxy downstream interface. Those situations count as a General Query loss, ngl 💀. To avoid erroneous query timeouts at the MAG, MLD parameters should be carefully adjusted to the mobility regime. Specifically, the MLD timers and the Robustness Variable (see Section 9 of [RFC3810]) should be chosen to match the time scale of handover operations and proxy configurations in the PMIPv6 domain ⏱️.
Doing it this way lets the MAG aggregate multicast subscriptions for each of its MLD proxy instances 🍓. However, this deployment approach does not stop multiple identical streams from arriving over different LMA upstream interfaces. Also, a multipoint channel forwarding into the wireless domain is prevented by the point-to-point link model in use 🌈.
4.3. Operations of the Local Mobility Anchor 👑
for any MN, the Local Mobility Anchor acts as the persistent home agent and also as the default multicast querier for the corresponding MAG 🦋. It implements the function of the designated multicast router or a further MLD proxy. Based on the MLD reports it gets from a MAG (on behalf of the MNs), the LMA establishes, maintains, and removes group-specific and source-specific multicast forwarding states on its corresponding downstream tunnel interfaces. At the same time, it takes care of aggregated multicast membership maintenance at its upstream interface 💅. Since the MAGs operate multicast-transparently, the LMA treats its tunnel interfaces as multicast-enabled downstream links that serve zero to many listening nodes 🫶. Multicast traffic arriving at the LMA gets transparently forwarded according to its multicast forwarding information base.
After a handover, the LMA receives Binding De-Registrations and Binding Lifetime Extensions. Those cause a re-mapping of the home network prefix(es) to a new Proxy-CoA in its Binding Cache (see Section 5.3 of [RFC5213]) ✨. The multicast forwarding states also need updating if the MN, inside an MLD proxy domain, is the only receiver of a multicast group. Two different cases need to be considered:
- The mobile node is the only receiver of a group behind the interface at which a De-Registration was received. The membership database of the MAG changes, which triggers a Report/Done sent via the MAG-to-LMA interface to remove this group. So the LMA stops multicast forwarding 🛑.
- The mobile node is the only receiver of a group behind the interface at which a Lifetime Extension was received. The membership database of the MAG changes, which triggers a Report sent via the MAG-to-LMA interface to add this group. So the LMA starts multicast distribution 🎉.
Doing it this way means each LMA provides transparent multicast support for the group of MNs it serves 🌸. It does traffic aggregation at the MN-group level and makes sure multicast data streams are uniquely forwarded per individual LMA-to-MAG tunnel 💖.
4.4. IPv4 Support 🎀
an MN in a PMIPv6 domain can use an IPv4 address transparently for communication, as specified in [RFC5844] 🌷. For this, LMAs can register IPv4-Proxy-CoAs in their Binding Caches, and MAGs can provide IPv4 support in access networks. Multicast membership management is handled by the MN using IGMP. On the network side, an IGMP proxy function needs to be deployed at MAGs in exactly the same way as it is for IPv6. [RFC4605] defines IGMP proxy behavior in full agreement with IPv6/MLD, so IPv4 support can be transparently provided by following the obvious deployment analogy 🧚.
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances should choose multicast signaling according to the address configurations on the link, but they may submit IGMP and MLD queries in parallel if needed 💅. It's also worth noting that the infrastructure cannot identify two data streams as identical when they're distributed via an IPv4 and an IPv6 multicast group. So duplicate data may be forwarded on a heterogeneous network layer 😭.
There's a special case worth calling out: the scenario of [RFC5845], where overlapping private address spaces of different operators can be hosted in a PMIP domain by using Generic Routing Encapsulation (GRE) with key identification 🔥. In this scenario, unicast communication in the MAG-LMA tunnel can be individually identified per MN by the GRE keys. This scenario still does not impose any special treatment of multicast communication, for the following reasons.
MLD/IGMP signaling between MNs and the MAG runs on point-to-point links, which is identical to unicast. Aggregated MLD/IGMP signaling between the MAG proxy instance and the LMA stays link-local between the routers and is independent of any individual MN. So the MAG-proxy and the LMA should not use GRE key identifiers, but plain GRE, 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 it is independent of the MN's unicast addresses. Meanwhile, the MAG proxy instance distributes multicast data down the point-to-point links (interfaces) according to its own MFIB, independent of the MN's IP addresses 🌈.
It remains an open issue how communication proceeds in a multi-operator scenario, meaning from which network the LMA pulls multicast traffic. This could be any mobility operator itself, or a third party. However, this backbone routing is out of scope for the document in general, and most likely a matter of contracts 🙈.
4.5. Multihoming Support 🫧
an MN can connect to a PMIPv6 domain through multiple interfaces and experience transparent unicast handovers at all interfaces (cf., Section 5.4 of [RFC5213]) 💖. In these simultaneous access scenarios, it can autonomously assign multicast channel subscriptions to individual interfaces (see [RFC5757] for additional details) 💅. While doing that, the multicast mobility operations described in this document transparently preserve the association of channels to interfaces, in the following way.
Multicast listener states are kept per interface in the MLD state table. An MN answers an MLD General Query received on a specific (re-attaching) interface according to that specific interface's state table. After that, multicast forwarding resumes for channels identical to the ones under subscription prior to the handover ✨. So an MN in a PMIPv6 domain may use multiple interfaces to facilitate load balancing or redundancy, but it cannot follow a 'make-before-break' approach to service continuation on handovers 😭.
4.6. Multicast Availability throughout the Access Network 🌸
there may be deployment scenarios where multicast services are available throughout the access network, independent of the PMIPv6 infrastructure 🧚. Direct multicast access at MAGs may be supported through native multicast routing within a flat access network that includes a multicast router. It can also be done via dedicated (tunnel or VPN) links between MAGs and designated multicast routers, or by deploying Automatic Multicast Tunneling (AMT) [AUTO-MULTICAST].
Multicast deployment can be simplified in these scenarios 🍓. A single proxy instance at MAGs with an up-link to the multicast cloud, for instance, could serve group communication purposes. MAGs could operate as general multicast routers or AMT gateways as well 🎀.
What all these solutions have in common is that mobility management is covered by the dynamics of multicast routing, as initially foreseen in the Remote Subscription approach. That means joining via a local multicast router, as sketched in [RFC3775] 💜. Care must be taken to avoid avalanche problems or service disruptions caused by tardy multicast routing operations, and to adapt to different link-layer technologies [RFC5757] ⚠️. The different possible approaches should be carefully investigated beyond the initial sketch in Appendix C. Such work is beyond the scope of this document 🦋.
4.7. A Note on Explicit Tracking ✨
okay so an IGMPv3/MLDv2 Querier can totally team up with explicit tracking, as described in Appendix A.2 of [RFC3376] or Appendix A.2 of [RFC3810] 💅. It lets routers keep tabs on each multicast receiver individually 👀. ngl, this procedure isn't standardized yet, but vendors are literally already implementing it because it gives you faster leave latencies and reduced signaling 🔥.
Enabling explicit tracking on the downstream interfaces of the LMA and MAG would track a single MAG and MN respectively per interface 🧚. It may be used to preserve bandwidth on the MAG-MN link 🌸.
5. Message Source and Destination Address 🎀
this section is all about the source and destination addresses of MLD messages and the encapsulating outer headers when you deploy this in the PMIPv6 domain 🦋. it's just for clarification, so it doesn't define any behavior that's different from the referenced standards, not even a little 🫶.
the interface identifier A-B means an interface on node A that's connected to node B 💜. this includes tunnel interfaces. destination addresses for MLD/IGMP messages shall be as specified in Section 8 of [RFC2710] for MLDv1, and Sections 5.1.15 and 5.2.14 of [RFC3810] for MLDv2 ✨.
5.1. Query
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+5.2. Report/Done
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+6. Security Considerations 🔒
this document doesn't bring in any extra messages or brand-new protocol operations 🙈. so no additional threats come with it beyond the security concerns already identified in [RFC3810], [RFC4605], [RFC5213], and [RFC5844] 💀.
however, you really should pay particular attention to what happens when you combine multicast and mobility management at network entities. this spec lets mobile nodes kick off the creation of multicast forwarding states at MAGs and LMAs while they're switching attachments, so threats of resource exhaustion at PMIP routers and access networks come from rapid state changes, and also from high-volume data streams routed into access networks with limited capacity 😭. on top of proper authorization checks of MNs, rate controls at replicators may be required to protect the agents and the downstream networks 🔥. in particular, MLD proxy implementations at MAGs should carefully arrange automatic multicast state extinction when MNs depart, because mobile multicast listeners in the PMIPv6 domain won't actively terminate group membership before they leave 🚨.
7. Acknowledgements 🫶
this memo builds on the initial requirements work presented in "Multicast Support Requirements for Proxy Mobile IPv6" (July 2009) 🌈. it's the result of lots of previous discussions and follows up on several early documents about the topic 🧚. the authors want to thank (in alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley, Gorry Fairhurst, Dirk von Hugo, Liu Hui, Seil Jeon, Jouni Korhonen, Guang Lu, Sebastian Meiling, Akbar Rahman, Imed Romdhani, Behcet Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for advice, help, and reviews of the document 💖. funding by the German Federal Ministry of Education and Research within the G-LAB Initiative is gratefully acknowledged 🙌.
8. References 📚
8.1. Normative References
[RFC2710]Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.[RFC3376]Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.[RFC3775]Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.[RFC3810]Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.[RFC4605]Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.[RFC5213]Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.[RFC5844]Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
8.2. Informative References
[AUTO-MULTICAST]Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Pusateri, "Automatic IP Multicast Without Explicit Tunnels (AMT)", Work in Progress, March 2010.[RFC2236]Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.[RFC5757]Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010.[RFC5845]Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
Appendix A. Initial MLD Queries on Upcoming Links 🧚
according to [RFC3810] and [RFC2710], when an IGMP-/MLD-enabled multicast router starts operating on a subnet, it defaults to thinking it's the querier and sends several General Queries 👑. that initial query should be sent by the router immediately, but it could be delayed by a (tunable) Startup Query Interval (see Sections 7.6.2 and 9.6 of [RFC3810]) ⏱️.
experimental tests on Linux and Cisco systems showed immediate IGMP Queries following a link trigger event (within a fraction of 1 ms), while MLD queries immediately followed the autoconfiguration of IPv6 link-local addresses at the corresponding interface ✨.
Appendix B. State of IGMP/MLD Proxy Implementations 🌸
the deployment scenario defined in this document needs certain proxy functionalities at the MAGs, and implementations of [RFC4605] need to contribute to them 💅. specifically, you need simultaneous support for IGMP and MLD, a configurable list of downstream interfaces that can be altered at runtime, and the ability to deploy multiple proxy instances on a single router that operate independently on separate interfaces 🎀.
a brief experimental trial in February 2010 revealed these divergent statuses of selected IGMP/MLD proxy implementations 🔍:
- Cisco Edge Router: software-based commodity edge routers (test device from the 26xx-Series) implement IGMPv2/v3 proxy functions only in combination with Protocol Independent Multicast - Sparse Mode (PIM-SM) 🙃. there's no MLD proxy support. interfaces are dynamically configurable at runtime via the command line interface, but multiple proxy instances aren't supported 🙅♀️.
- Linux igmpproxy: IGMPv2 proxy implementation that permits a static configuration of downstream interfaces (simple bug fix required) 🛠️. multiple instances are prevented by a lock (corresponding code reused from a previous Distance Vector Multicast Routing Protocol (DVMRP) implementation). IPv6/MLD is unsupported. project page:
http://sourceforge.net/projects/igmpproxy/🔗. - Linux gproxy: IGMPv3 proxy implementation that permits configuration of the upstream interface only 😤. downstream interfaces are collected at startup without dynamic extension of this list. no support for multiple instances or MLD 💀.
- Linux ecmh: MLDv1/2 proxy implementation without IGMP support that inspects IPv4 tunnels and detects encapsulated MLD messages 🦋. it allows dynamic addition of interfaces at runtime and multiple instances ✅. however, downstream interfaces cannot be configured 🥲. project page:
http://sourceforge.net/projects/ecmh/
Appendix C. Comparative Evaluation of Different Approaches 🎀
Okay bestie, this section is where we compare two PMIP multicast approaches side by side 👀💅. In scenario A, multicast comes from combined unicast/multicast LMAs, which is the approach this document describes. Scenario B sends traffic through a dedicated central multicast router called "LMA-M", which tunnels packets to MAGs no matter what unicast handoffs are happening 🦋.
Neither approach sets up native multicast distribution between the LMA and MAG. Both use tunneling instead 🧚. In scenario A, a MAG can be connected to several multicast-enabled LMAs, so it can receive the same multicast stream over multiple paths, depending on which groups the MNs subscribe to and which LMAs they're attached to. This is the tunnel convergence problem (a.k.a. the tunnel convergence problem 💀), and it can cause redundant traffic at the MAGs. Scenario B is the opposite vibe ✨. Each MAG sets up one tunnel to a single dedicated multicast LMA for all of its attached MNs, so the overhead moves over to the multicast anchor. That kills the redundant traffic, but it can cause an avalanche problem at the LMA 😭.
We measure the cost of both approaches with two metrics: how much redundant traffic shows up at the MAGs, and how many simultaneous streams the LMAs are juggling 📊. Real numbers depend on the topology and the group subscription model, so to see how things scale in a big PMIP domain of 1,000,000 MNs, we look at two extreme multicast settings 🌈.
- All MNs participate in distinct multicast groups.
- All MNs join the same multicast group.
Here's the math: a typical PMIP deployment fits roughly 5,000 MNs on one MAG, and one LMA can serve 50 MAGs 🍓. So 1,000,000 MNs need about 200 MAGs backed by 4 LMAs for unicast. In scenario A, those same LMAs also forward the multicast streams. In scenario B, one extra dedicated LMA (LMA-M) handles multicast. Next, we calculate the metrics above, and we also show how many packet streams cross the interconnecting (wired) network inside a PMIPv6 domain 🔥.
Setting 1:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 0 | 250,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 1,000,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to distinct multicast groups.Setting 2:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 3 | 200 | 800 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 200 | 200 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to the same multicast group.So what do these extreme cases tell us? 🤔 Packet duplication and replication show up with different intensities depending on the multicast data service use case 💜. Tunnel convergence (duplicate data landing at a MAG) causes much smaller scalability problems than stream replication at the LMAs, which is the avalanche problem 😤. For scenario A, the heavy stream replication at LMAs in setting 1 can be eased by deploying extra LMAs in the PMIP domain 🫶. Scenario B doesn't have that option, though, because LMA-M can't be distributed. No handover management is available at LMA-M, so it has to stay as one box 🙈.
Authors' Addresses ✨
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidtMatthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
EMail: mw@link-lab.netSuresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
EMail: suresh.krishnan@ericsson.com📦 where this page comes from
- ietf: rfc6224 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms