RFC 7287
Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
RFC 7287: Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains 🎀
Okay bestie, let's get into this one 💖. It's an Experimental doc (so it's not a Standards Track spec, just something people are testing out 🧪), published by the IETF in June 2014 with ISSN 2070-1721. The authors are T. Schmidt, Ed. (HAW Hamburg), S. Gao and H. Zhang (both Beijing Jiaotong University), and M. Waehlisch (link-lab & FU Berlin). There are no Obsoletes or Updates listed in its header 👀.
Abstract ✨
Okay so multicast can work in PMIPv6 domains 🌸. The trick is using the Local Mobility Anchors and putting MLD proxy functions on the Mobile Access Gateways, using direct traffic distribution in an ISP's access network, or doing selective route optimization. This doc gives a base solution plus an experimental protocol that helps mobile multicast senders in PMIPv6 domains for all three of those scenarios 🦋. It also defines protocol optimizations for syncing PMIPv6 with PIM, and a peering function for MLD proxies 💅. The best part is that mobile sources never have to care about multicast mobility stuff at all 🫶.
Status of This Memo ✨
This one is not an Internet Standards Track spec 🙈. It's out there for people to look at, try implementing as an experiment, and evaluate.
It does define an Experimental Protocol for the Internet community 🧪. It's a product of the IETF and reflects IETF consensus. It got public review and the IESG approved it for publication. Not everything the IESG approves is going to become an Internet Standard, so see Section 2 of RFC 5741 for that 🌈.
If you want the latest status, errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc7287 🔥.
Copyright Notice 💜
Copyright (c) 2014 IETF Trust and the document authors, all rights reserved 🎀. This doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Please actually read those, because they spell out your rights and restrictions 🙈. Any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 💅.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . 9
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 12
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 14
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 15
4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 16
4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 16
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 17
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 18
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 18
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 19
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 19
5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Operations in Support of Multicast Senders . . . . . . . 20
5.4. Operations in Support of Multicast Listeners . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 26
A.1. Operations for Local Multicast Sources . . . . . . . . . 26
A.2. Operations for Local Multicast Subscribers . . . . . . . 26
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 271. Introduction ✨
Okay so Proxy Mobile IPv6 (PMIPv6) [RFC5213] is basically an extension of Mobile IPv6 (MIPv6) [RFC6275] 💖. It adds network-based management functions, so a host gets IP mobility without having to take part in any mobility signaling at all 🧚. The network handles it with entities called Local Mobility Anchor (LMAs) and Mobile Access Gateways (MAGs), which manage mobility for the mobile node (MN) 🦋. Here's the catch: an MN on a PMIPv6 domain that only follows the base specs of [RFC5213] can't join multicast communication, because MAGs will throw away group packets 🙈.
Multicast for mobile listeners can work in a PMIPv6 domain, though 🌸. You put MLD proxy functions on the Mobile Access Gateways, and multicast routing functions on the Local Mobility Anchors [RFC6224]. This base option is the simplest way to add PMIPv6 multicast, because it follows the usual PMIPv6 traffic model and doesn't need any new protocol operations or extra infrastructure entities 💅. You just turn on standard software functions on the PMIPv6 entities. The downside is that the multicast routing might be non-optimal 😭.
There are fancier options for better performance too ⭐. You can do multicast routing right at the access gateways [MULTI-EXT], or use selective route optimization schemes [RFC7028]. Both of these (partly) follow the model where multicast data services run alongside PMIPv6 unicast routing [RFC7161] 🫶.
Multicast listener support is great for receptive use cases like IPTV or server-centric gaming on phones 🎮. But the internet is moving toward user-centric, super interactive group apps, like user-generated streaming, conferencing, collective mobile sensing, and more 🔥. A lot of these apps make group content on end systems, and they'd really benefit from sending data directly to a multicast-enabled network 👑.
So this doc covers mobile multicast senders in Proxy Mobile IPv6 domains for the base deployment scenario [RFC6224], for direct traffic distribution within an ISP's access network, and for selective route optimization schemes 💜. The source mobility problem described in [RFC5757] is the foundation here 🌈. Mobile nodes in this setup still don't have to care about multicast mobility operations 🫶.
2. Terminology 📖
This doc uses the terminology from the mobility protocols [RFC6275], [RFC5213], and [RFC5844], plus the multicast routing spec [RFC4601] and the edge-related protocols [RFC3376], [RFC3810], and [RFC4605] 💅.
Throughout the doc, we use these acronyms 🎀:
HNP Home Network Prefix as defined in [RFC5213].
MAG Mobile Access Gateway as defined in [RFC5213].
MLD Multicast Listener Discovery as defined in [RFC2710] and
[RFC3810].
PIM Protocol Independent Multicast as defined in [RFC4601].
PMIPv6 Proxy Mobile IPv6 as defined in [RFC5213].2.1. Requirements Language 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119] 🧠. Those words are the ones that carry the real requirement weight, so keep them in mind as you read ✨.
3. Base Solution for Source Mobility and PMIPv6 Routing 🦋
3.1. Overview ✨
okay so the reference setup for multicast in Proxy Mobile IPv6 domains is shown in Figure 1 🦋 It's the general vibe for source mobility: mobile nodes (MNs) with Home Network Prefixes (HNPs) get their services through tunnels that run between a Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address (Proxy-CoA) at a Mobility Access Gateway (MAG). The MAGs are the first-hop access routers serving lots of MNs downstream, and each one runs an MLD/IGMP proxy instance for every LMA upstream tunnel 🌸
+-------------+
| Multicast |
| Listeners |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* 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 MN3
Multicast Sender + Listener(s)Figure 1: Reference Network for Multicast Deployment in PMIPv6
Here's the vibe: an MN in a PMIPv6 domain decides whether to send multicast totally independent of how it's moving around 🧚 It just sends packets the way its apps tell it to, using a source address from its HNP and a multicast destination address that matches what the apps need. Multicast packets show up at whichever MAG is currently active, through one of its downstream local (wireless) links. A MAG that doesn't know about multicast would just drop these packets if it has no instructions for processing them, which means it has no Multicast Routing Information Base (MRIB) 💀
An MN can totally distribute multicast data in PMIPv6 as long as MLD proxy functions are set up at the MAG, as described in [RFC6224] 🎀 In this setup, the MLD proxy instance serving a mobile multicast source has its upstream interface on the tunnel heading to that MN's corresponding LMA. Every LMA gets its own separate MLD proxy instance 💅
Now, according to [RFC4605], multicast data that comes in from a downstream interface of an MLD proxy gets forwarded to the upstream interface, plus all the other downstream interfaces that have the right forwarding state for that group, except the one it came in on 🫶 So multicast streams from an MN reach the corresponding LMA, and they also go straight to every mobile receiver sitting at the same MAG and MLD proxy instance. The LMA can be the designated multicast router or an extra MLD proxy. As the designated multicast router, it sends data out to the fixed Internet whenever multicast routing has forwarding states in place. If the LMA is acting as another MLD proxy instead, it forwards the multicast data to its upstream interface and to its downstream interfaces with matching subscriptions 🔥
Handovers are where it gets spicy 😭 The MN doesn't know about IP mobility, but it can keep sending multicast packets as soon as network connectivity comes back. By then the MAG has already figured out the corresponding LMA, and the IPv6 unicast address configuration (including the PMIPv6 bindings) is finished. Even so, multicast packets that reach the MAG get thrown away (unless they're buffered) until the MAG finishes these two steps:
- The MAG has determined that the MN is admissible to multicast services.
- The MAG has added the new downstream link to the MLD proxy instance that has an uplink to the corresponding LMA.
The second the MN's uplink is linked up with the corresponding MLD proxy instance, multicast packets flow again to the LMA and eventually reach receivers inside the PMIP domain ✨ (Check out the call flow in Figure 2 🍓) That's how multicast source mobility just works, transparently, in PMIPv6 domains that use the base multicast scenario 👑
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| | Mcast Data | | |
| |<---------------+ | |
| | Mcast Data | | |
| Join(G) +================================================>|
+--------------> | | | |
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | < MLD Proxy Configuration > |
| | | | |
| | | (MLD Query) | |
| | |<--------------+ |
| | | Mcast Data | |
| | +-------------->| |
| | | | Mcast Data |
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| Mcast Data | | | |
|<---------------+ | | |
| | | | |Legend: Rtr Sol - ICMPv6 Router Solicitation Rtr Adv - ICMPv6 Router Advertisement
Figure 2: Call Flow for Group Communication in Multicast-Enabled PMIP
These multicast deployment ideas also apply to mobile nodes running their IPv4 stack in a PMIPv6 domain 🦋 PMIPv6 can offer IPv4 home address mobility support [RFC5844], and IPv4 multicast is handled by an IGMP proxy function at the MAG in a similar way 🧚
Once you follow these deployment steps, multicast traffic distribution works transparently with PMIPv6 💖 One thing worth knowing: an MN that's attached to the same MAG as the mobile source, but associated with a different LMA, can't receive multicast traffic on a shortest path 🙈 Instead, the multicast streams go up to the LMA of the mobile source, get transferred to the LMA of the mobile listener, and then get tunneled back down to the MAG (see Section 5 for further optimizations 🌈)
3.2. Base Solution for Source Mobility: Details ✨
Supporting multicast source mobility in PMIPv6 requires that general multicast functions get deployed at PMIPv6 routers, and that their interactions with the PMIPv6 protocol are defined as follows 🫶
3.2.1. Operations of the Mobile Node 🌸
An MN that wants to send multicast data just proceeds as if it were attached to the fixed Internet. No specific mobility or other multicast-related functionalities are required at the MN 💅
3.2.2. Operations of the Mobile Access Gateway 🎀
A Mobile Access Gateway is required to have MLD proxy instances deployed, one for each tunnel to an LMA, and that LMA serves as its unique upstream link (cf. [RFC6224]) 🦋 When an MN arrives, the MAG decides how to map downstream links to a proxy instance, and how to map the upstream link to the LMA, based on the regular Binding Update List that's maintained by standard PMIPv6 operations ✨ When multicast data is received from the MN, the MAG MUST identify the corresponding proxy instance from the incoming interface, and then forwards multicast data upstream according to [RFC4605] 🔥
The MAG MAY apply special admission control to enable multicast data transmission from an MN 👑 It's advisable to take special care that MLD proxy implementations don't redistribute multicast data to downstream interfaces without appropriate subscriptions in place 💀
3.2.3. Operations of the Local Mobility Anchor 👑
For any MN, the Local Mobility Anchor acts as the persistent Home Agent, and at the same time as the default multicast upstream for the corresponding MAG 🧚 It manages and maintains a multicast forwarding information base for all group traffic arriving from its mobile sources 🍓 The LMA SHOULD participate in multicast routing functions that enable traffic redistribution to all adjacent LMAs within the PMIPv6 domain, and that way it keeps a continuous receptivity while the source is in motion 🌈
3.2.3.1. Local Mobility Anchors Operating PIM
Okay bestie, so Local Mobility Anchors running PIM-SM [RFC4601] need sources to be directly connected so they can send PIM registers to the Rendezvous Point (RP) 🫶. That is NOT the vibe in a PMIPv6 domain, because MAGs are routers sitting in between the MN and the LMA 😭. So from PIM-SM's point of view, MNs are multicast sources living outside the PIM-SM domain 🦋.
To fix this mismatch (it's common to every subsidiary MLD proxy domain 💅), the LMA MUST act as a PIM Border Router and activate the Border-bit ✨. Then DirectlyConnected(S) is treated as TRUE for mobile sources, and the PIM-SM forwarding rule iif == RPF_interface(S) is relaxed to TRUE, because the incoming tunnel interface from MAG to LMA is not considered part of the PIM-SM component of the LMA (see Appendix A.1 of [RFC4601]) 👑.
An LMA serving as the PIM Designated Router (DR) is connected to MLD proxies via individual IP tunnel interfaces, so it's going to experience changing PIM source states on handover 🌸. As the incoming interface connects to a point-to-point link, PIM Assert contention is not active, and incoming interface validation is only performed by Reverse Path Forwarding (RPF) checks. Consequently, a PIM DR SHOULD update incoming source states as soon as RPF inspection succeeds, i.e., after the PMIPv6 forwarding state update. Consequently, PIM routers SHOULD be able to manage these state changes, but some implementations are expected to incorrectly refuse packets until the previous state has timed out 💀.
Notably, running Bidirectional PIM (BIDIR-PIM) [RFC5015] on LMAs remains robust with respect to source location and does not require special configurations or state management for sources 🧚.
3.2.4. IPv4 Support
An MN in a PMIPv6 domain may use an IPv4 address transparently for communication as specified in [RFC5844] 🎀. For this purpose, an LMA can register an IPv4-Proxy-CoA in its Binding Cache, and the MAG can provide IPv4 support in its access network. Correspondingly, multicast membership management will be performed by the MN using IGMP. For multicast support on the network side, an IGMP proxy function needs to be deployed at MAGs in exactly the same way as for IPv6. [RFC4605] defines IGMP proxy behavior in full agreement with IPv6/MLD. Thus, IPv4 support can be transparently provided following the obvious deployment analogy 🍓.
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances SHOULD choose multicast signaling according to address configurations on the link, but they MAY submit IGMP and MLD queries in parallel, if needed. It should further be noted that the infrastructure cannot identify two data streams as identical when distributed via an IPv4 and IPv6 multicast group. Thus, duplicate data may be forwarded on a heterogeneous network layer 🙈.
The following points are worth noting about the scenario in [RFC5845], in which overlapping private address spaces of different operators can be hosted in a PMIP domain by using Generic Routing Encapsulation (GRE) with key identification. This scenario implies that 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.
Multicast streams from and to MNs arrive at a MAG on point-to-point links (identical to unicast). Multicast data transmission from the MAG to the corresponding LMA is link-local between the routers, and routing/forwarding remains independent of any individual MN. So, the MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain GRE in multicast communication (including MLD queries and reports). Multicast traffic is transmitted using router-to-router forwarding via the MAG-to-LMA tunnels and according to the MRIB of the MAG or the LMA. It remains independent of MN's unicast addresses, while the MAG proxy instance redistributes multicast data down the point-to-point links (interfaces) according to its local subscription states, independent of IP addresses of the MN 🦋.
3.2.5. Efficiency of the Distribution System
The distribution system of the base solution directly follows PMIPv6 routing rules and organizes multicast domains with respect to LMAs. Thus, no coordination between address spaces or services is required between the different instances, provided their associated LMAs belong to disjoint multicast domains. Routing is optimal for communication between MNs of the same domain or stationary subscribers ✨.
In the following situations, efficiency-related issues remain 👀:
- Multicast reception at LMA: In the current deployment scenario, the LMA will receive all multicast traffic originating from its associated MNs. There is no mechanism to suppress upstream forwarding in the absence of receivers.
- MNs on the same MAG using different LMAs: For a mobile receiver and a source that use different LMAs, the traffic has to go up to one LMA, cross over to the other LMA, and then be tunneled back to the same MAG, causing redundant flows in the access network and at the MAG.
These remaining deficits in routing efficiency can be resolved by adding peering functions to MLD proxies as described in Section 5 🫶.
4. Direct Multicast Routing ✨
There are deployment scenarios where multicast services are available throughout the access network, independent of the PMIPv6 routing system [RFC7028] 🌈. In these cases, the visited networks grant a local content distribution service (in contrast to LMA-based home subscription) with locally optimized traffic flows. It is also possible to deploy a mixed service model of local and LMA-based subscriptions, provided that a unique way of service selection is implemented. For example, access routers (MAGs) could decide on service access based on the multicast address G or the source-specific multicast (SSM) channel (S,G) under request. (See Appendix A for further discussions.) 💜
4.1. Overview
Direct multicast access can be supported by:
- native multicast routing provided by one multicast router that is neighboring MLD proxies deployed at MAGs within a flat access network, or via tunnel uplinks,
- a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM [RFC5015] deployed at the MAGs.
*** *** *** ***
* ** ** ** *
* *
* Multicast *
+----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+
| // \\ |
\\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *//
|| || || || * || Routing || *
+----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***|
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
Figure 3: Reference Networks for (a) Proxy-Assisted Direct Multicast
Access and (b) Dynamic Multicast Routing at MAGsFigure 3 displays the corresponding deployment scenarios that separate multicast from PMIPv6 unicast routing 🧜. It is assumed throughout these scenarios that all MAGs (MLD proxies) are linked to a single multicast routing domain. Notably, this scenario requires coordination of multicast address utilization and service bindings.
Multicast traffic distribution can be simplified in these scenarios. A single proxy instance at MAGs with uplinks into the multicast domain will serve as a first-hop multicast gateway and avoid traffic duplication or detour routing. Multicast routing functions at MAGs will seamlessly embed access gateways within a multicast cloud ☁️. However, mobility of the multicast source in this scenario will require some multicast routing protocols to rebuild distribution trees. This can cause significant service disruptions or delays (see [RFC5757] for further aspects) 😭. Deployment details are specific to the multicast routing protocol in use; this is described below for common protocols.
4.2. MLD Proxies at MAGs
In a PMIPv6 domain, single MLD proxy instances can be deployed at each MAG that enable multicast service at the access via an uplink to a multicast service infrastructure (see Figure 3(a)). To avoid service disruptions on handovers, the uplinks of all proxies SHOULD be adjacent to the same next-hop multicast router. This can either be achieved by arranging proxies within a flat access network or by using upstream tunnels that terminate at a common multicast router 🎀.
Multicast data submitted by a mobile source will reach the MLD proxy at the MAG, which subsequently forwards flows to the upstream and to all downstream interfaces with appropriate subscriptions. Traversing the upstream will transfer traffic into the multicast infrastructure (e.g., to a PIM Designated Router), which will route packets to all local MAGs that have joined the group, as well as further upstream according to protocol procedures and forwarding states.
On handover, a mobile source will reattach to a new MAG and can continue to send multicast packets as soon as PMIPv6 unicast configurations have been completed. Like at the previous MAG, the new MLD proxy will forward data upstream and downstream to subscribers. Listeners local to the previous MAG will continue to receive group traffic via the local multicast distribution infrastructure, following aggregated listener reports of the previous proxy. In general, traffic from the mobile source continues to be transmitted via the same next-hop multicast router, using the same source address, and thus remains unchanged when seen from the wider multicast infrastructure 🦋.
4.2.1. Considerations for PIM-SM on the Upstream
A mobile source that transmits data via an MLD proxy will not be directly connected to a PIM Designated Router, as discussed in Section 3.2.3.1. Countermeasures apply correspondingly 💅.
A PIM Designated Router that is connected to MLD proxies via individual IP tunnel interfaces will experience invalid PIM source states on handover. In some implementations of PIM-SM, this could lead to an interim packet loss (see Section 3.2.3.1). This problem can be mitigated by aggregating proxies on a lower layer 🧚.
4.2.2. SSM Considerations
Source-specific subscriptions invalidate with routes whenever the source moves from or to the MAG/proxy of a subscriber. Multicast forwarding states will rebuild with unicast route changes. However, this may lead to noticeable service disruptions for locally subscribed nodes 🥺.
4.3. PIM-SM at MAGs ✨
Okay bestie, so PIM-SM is the full-featured multicast routing protocol, and it's allowed (MAY) to be deployed in the access network so multicast services can run alongside unicast routes 💖 (see Figure 3(b)). For the rest of this section, we're assuming the whole PMIPv6 mobility domain is one PIM-SM multicast routing domain, with PIM-SM routing functions at every MAG and every LMA 🫶. The PIM routing instance at a MAG SHALL then act as the Designated Router (DR) for all directly attached Mobile Nodes 👑. To make handovers go faster, it's advisable to park the PIM Rendezvous Points (RPs) in the core of the PMIPv6 network domain 🧚. Lowkey though, regular IP routing tables don't need to be present in a PMIPv6 deployment, so you'll have to put in some extra effort to set up the reverse path forwarding rules that PIM-SM needs 😭.
4.3.1. Routing Information Base for PIM-SM 🗺️
In this setup, PIM-SM is going to rely on a Multicast Routing Information Base (MRIB) that gets generated separately from the policy-based routing rules of PMIPv6 🌸. How granular the mobility-related routing locators need to be depends on how complex (which phase) the PIM deployment is.
For all three phases of PIM (see [RFC4601]), you'll need the following info 💅.
- All routes to networks and nodes (including RPs) that are not mobile members of the PMIPv6 domain MUST be defined consistently among PIM routers and MUST remain unaffected by node mobility. Setting up these general routes is expected to follow the topology of the operator network, and that's beyond the scope of this document 🍓.
Next up, these route entries are required at a PIM-operating MAG when phase two or three of PIM or PIM-SSM is in operation 🔥.
- Local routes to the Home Network Prefixes (HNPs) of all MNs, associated with their corresponding point-to-point attachments, that MUST be included in the local MRIB 🎀.
- All routes to MNs that are attached to distant MAGs of the PMIPv6 domain point towards their corresponding LMAs. These routes MUST be made available in the MRIB of all PIM routers (except for the local MAG of attachment), but they MAY be eventually expressed by an appropriate default entry 🦋.
4.3.2. Operations of PIM in Phase One (RP Tree) 🌳
A brand new mobile source S sends its multicast data for group G to its MAG of attachment 🚀. The access gateway, acting as a PIM DR, unicast-encapsulates those multicast packets and forwards them to the Virtual Interface (VI) with the encapsulation target RP(G). This whole thing is called "PIM source registering" 💜. The RP decapsulates the packets and natively forwards them down the RP-based distribution tree to the subscribers, both mobile and stationary ✨.
Now, when a handover happens, the point-to-point link between the mobile source and the old MAG goes down, and all (S,*) flows terminate 💀. The previous DR (MAG) reacts by switching off the data encapsulation channels for the transient source (i.e., all DownstreamJPState(S,*,VI) are set to NoInfo state). Once the source has reattached and finished the unicast handover negotiations, it can keep transmitting multicast packets. At its new DR (MAG), though, it gets treated as a brand new source 🌈. Source register encapsulation kicks in right away, and (S,G) data keeps flowing natively down the (*,G) RP-based tree 🧚.
Source handover management in PIM phase one is low complexity and stays transparent to receivers, which is so iconic 🙌. Plus, the source register tunnel management of PIM is a fast protocol operation with very little overhead ⭐. In a PMIPv6 deployment, PIM RPs MAY be configured to uninitiated (S,G) shortest path trees for mobile sources, which means they stay in phase one of the protocol. The catch with this simplified setup is possible routing detours, since everything gets distributed overall through the RP 😬.
4.3.3. Operations of PIM in Phase Two (Register-Stop) 🛤️
After it receives source register packets, a PIM RP will eventually start a source-specific Join to build a shortest path tree to the (mobile) source S, and it sends a source register stop once data from S arrives natively 🫣. To start an (S,G) tree, the RP and all the intermediate routers need route entries for the HNP of the MN, which point towards the corresponding LMA of S, unless the RP happens to be the MAG of S 💖. So the (S,G) tree goes from the RP through the (stable) LMA, down the LMA-MAG tunnel, and reaches the mobile source. Heads up, though: this tree can be less routing-efficient than the PIM source register tunnel from phase one 🙈.
When a handover happens, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management moves the LMA-MAG tunnel over to the new point of attachment ✈️. But with no matching multicast forwarding state, the new DR treats S as a new source and starts source registering in PIM phase one with the RP 🌀. The PIM RP then notices the known source on a new (tunnel) interface and immediately responds with a register stop. Since the RP had already joined the shortest path tree towards the source via the LMA, it sees an RPF change when data shows up on a new interface 👀. How this gets handled depends on the implementation, and it can trigger an update of the PIM MRIB plus a new PIM Join message that installs the multicast forwarding state that's missing at the new MAG 🔧. Otherwise, the tree gets periodically refreshed by Joins sent towards the new MAG on a path via the LMA 🔁. Doing it this way means PIM's transition from phase one to phase two gets a quick recovery on every handover 🏃♀️.
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 🏁
When a packet transmission threshold gets exceeded, the DRs of receivers will eventually start a source-specific Join to build a shortest path tree to the (mobile) source S, and that moves PIM into the final shortcut, phase three 🏎️. For every receiver that doesn't share a MAG with S, this (S,G) tree runs from the receiving DR, through the (stable) LMA and the LMA-MAG tunnel, and then through the serving MAG to the mobile source. It's more routing-efficient than the phase two tree, but it doesn't necessarily beat the PIM source register tunnel from phase one 🤷♀️. The upside is that receivers sharing a MAG with S get immediate data delivery 🌟.
On handover, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management moves the LMA-MAG tunnel to the new point of attachment 🛸. Without a matching multicast forwarding state, the new DR treats S as a new source and starts source registering in PIM phase one. A PIM implementation that handles this change properly can recover the phase three states like this. First, the RP recovers to phase two, as described in the previous section, and it won't forward data arriving through the source register tunnel 🙅♀️. Tree maintenance, which gets triggered by the RPF change (see Section 4.3.3), eventually generates the right states for native forwarding from the new MAG via the LMA 🧩. After that, packets reaching the LMA without source register encapsulation get forwarded natively along the shortest path tree towards the receivers 🎯.
So in the end, PIM's transitions from phase one to two to three get quickly recovered on each handover, but they still lead to extra signaling load and some intermediate packet loss 📉.
4.3.5. PIM-SSM Considerations 🔐
Source-specific Joins from receivers make PIM operate in SSM mode, which leads to an immediate setup of source-specific shortest path trees 💫. These (S,G) trees match the distribution system of PIM's final phase three (see Section 4.3.4). But here's the plot twist: on handover, and without RP-based data distribution, SSM data delivery can't resume through source registering like it does in PIM phase one 😱. So data packets sent after a handover get discarded at the MAG until regular tree maintenance has rebuilt the (S,G) forwarding state at the new MAG 🚫.
4.3.6. Handover Optimizations for PIM ⚡
Source-specific shortest path trees get built in PIM-SM (phase two and three) and in PIM-SSM. These RPF-trees run through LMA-MAG tunnels towards a source 🌊. PIM doesn't know anything about source mobility management, so these trees get invalidated during handovers, with every tunnel re-establishment at a new MAG 💔. Regular tree maintenance in PIM will recover the states, but it's unsynchronized and too slow to seamlessly keep PIM data distribution services going 🐢.
A method to quickly recover PIM (S,G) trees during a handover SHOULD synchronize multicast state maintenance with unicast handover operations, and it can go like this 🧠. On handover, an LMA reads all (S,G) Join states from its corresponding tunnel interface and figures out which source addresses S_i match the moving HNPs 🔍. After the new tunnel is re-established, it SHOULD associate the (S_i,*) Join states with the new tunnel endpoint, and immediately trigger a state maintenance (PIM Join) message 📨. That way, the source-specific PIM states move over to the new tunnel endpoint and get propagated to the new MAG in sync with the unicast handover procedures 💞.
4.4. BIDIR-PIM 🔄
BIDIR-PIM MAY be deployed in the access network so multicast services can run alongside unicast routes 🌷. For the rest of this section, we're assuming the PMIPv6 mobility domain is one single BIDIR-PIM multicast routing domain, with BIDIR-PIM routing functions at all MAGs and all LMAs 🫧. The PIM routing instance at a MAG SHALL then serve as the Designated Forwarder (DF) for all directly attached Mobile Nodes 🎀. To speed up handover operations, it's advisable to put the BIDIR-PIM Rendezvous Point Addresses (RPAs) in the core of the PMIPv6 network domain 🏰. Since regular IP routing tables don't need to be present in a PMIPv6 deployment, reverse path forwarding rules as required by BIDIR-PIM need to be set up 🛠️.
4.4.1. Routing Information Base for BIDIR-PIM 🗺️
In this scenario, BIDIR-PIM is going to rely on a Multicast Routing Information Base (MRIB) that gets generated separately from the policy-based routing rules of PMIPv6 💅. The following info is needed.
- All routes to networks and nodes (including RPAs) that are not mobile members of the PMIPv6 domain MUST be defined consistently among BIDIR-PIM routers and remain unaffected by node mobility. Setting up these general routes is expected to follow the topology of the operator network, and that's beyond the scope of this document 🌍.
4.4.2. Operations of BIDIR-PIM ✨
okay so BIDIR-PIM builds spanning trees across its whole network domain 🌸 following the pre-configured RPAs and the routing info it's given. When a mobile source sends multicast data, its DF (MAG) just forwards it straight onto the spanning tree for that group. No extra protocol steps 🦋
When the mobile source hands over, it reattaches to a new MAG (DF), which finishes the unicast network configuration. After that, the source can immediately start sending multicast onto the distribution tree that's already there ✨ BIDIR-PIM doesn't need any protocol signaling or extra reconfiguration delays to handle source mobility, so it's honestly giving protocol of choice for mobile multicast in the access network 👑 Just remember that multicast streams always flow up to the Rendezvous Point Link, so some care should be taken to configure RPAs that fit within network capacities 💅
5. MLD Proxy Peering Function for Optimized Source Mobility in PMIPv6 🌈
okay so MLD proxies (see [RFC4605]) at MAGs have been a super useful, appropriate way to do multicast in PMIPv6; see [RFC6224] and [RFC7028] ✨ BUT deploying unmodified standard proxies can come with big performance problems for mobile senders, as discussed in this document 🙈 So this section defines an optimized approach to multicast source mobility, based on extended peering functions among proxies. Because proxies exchange data directly, triangular routing is avoided, and multicast streams can be disseminated directly inside the PMIPv6 access network, even within MAG routing machines 🧚 First, let's go over the requirements.
5.1. Requirements 💅
Solutions that extend MLD proxies with additional uplinking functions need to comply with the following requirements.
- Prevention of routing loops: Without full-featured routing logic at an MLD proxy, simple and locally decidable rules need to stop source traffic from looping through the network, which multiple uplinks could potentially enable 🔁
- Unique coverage of receivers: Listener functions at proxies need simple, locally decidable rules to kick off a unique delivery of multicast packets to all receivers 🎯
Following local filtering techniques, these requirements are met in the following solution ✨
5.2. Overview 🫶
A peering interface for MLD proxies lets locally attached multicast sources exchange data directly. These peering interfaces can be configured, as a direct link or a bidirectional tunnel, between any two proxy instances (locally deployed as in [RFC6224] or remotely deployed) 💜 Peerings just sit there as silent virtual links during regular proxy operations. Data only moves over them when one peering proxy, on its downstream, directly connects to a multicast source that the other peering proxy actively subscribes to. In that case, the proxy connected to the source gets a listener report on its peering interface and forwards traffic from its local source accordingly.
Worth noting: multicast traffic distribution on peering links does not follow reverse unicast paths to sources 🔥 In the following, operations are defined for Any-Source Multicast (ASM) and SSM, but they provide superior performance in the presence of source-specific signaling (IGMPv3/MLDv2) [RFC4604] ✨
5.3. Operations in Support of Multicast Senders 🌸
From a sender's point of view, an MLD proxy sees peering interfaces as restricted downstream interfaces. It installs and maintains source filters at its peering links that restrict data transmission to packets originating from a source attached locally on one of its downstream interfaces.
In detail, a proxy pulls the network prefixes attached to its downstream interfaces out of its configuration, and it MUST implement a source filter base at its peering interfaces that restricts data transmission to IP source addresses from its local prefixes. That filter base MUST be updated if and only if the downstream configuration changes (e.g., due to mobility) 🔄 Multicast packets that arrive from the upstream interface of the proxy are thus kept off every peering link. They're only forwarded to regular downstream interfaces with appropriate subscription states, and that's how multihop forwarding on peering links is prevented 🛑
Multicast traffic arriving from a locally attached source goes to the regular upstream interface and to all downstream interfaces with appropriate subscription states (i.e., regular proxy operations). On top of that, multicast packets of local origin are transferred to those peering interfaces with appropriate subscription states 🦋
5.4. Operations in Support of Multicast Listeners 👑
On the listener side, peering interfaces appear as preferred upstream links. The multicast proxy tries to receive multicast services on peering links for as many groups (channels) as possible. The general upstream interface configured according to [RFC4605] is only used for retrieving those groups (channels) that remain unavailable from peerings. Because of this extension of [RFC4605], an MLD proxy with peering interconnects ends up with several interfaces for pulling remote traffic: the regular upstream and the peerings 🧚 Traffic available from any of the peering links is mutually disjoint, but normally also available from the upstream. To prevent duplicate traffic from arriving at the listener side, the proxy:
- MAY delay aggregated reports to the upstream, and
- MUST apply appropriate filters to exclude duplicate streams.
In detail, an MLD proxy instance at a MAG first issues listener reports (in parallel) to all of its peering links. These links span at most one (virtual) hop 💅 Whenever certain group traffic (SSM channels) does not arrive from the peerings after a waiting time (default: 10 ms (node-local) and 25 ms (remote)), additional reports (complementary reports, in the case of SSM) are sent to the standard upstream interface ⏱️
Whenever traffic from a peering link arrives, an MLD proxy MUST install source filters at its upstream interfaces (as described in RFC 4605) in the following way:
- ASM with IGMPv2/MLDv1: When ASM is using IGMPv2/MLDv1 only, the proxy cannot signal source filtering to its upstream. So it applies
(S,*)ingress filters at its upstream interface for all sources S seen in traffic on the peering links. Noteworthy: unwanted traffic is still replicated to the proxy via the (wired) provider backbone, but it is not forwarded into the wireless access network 🙈 - ASM with IGMPv3/MLDv2: In the presence of source-specific signaling (IGMPv3/MLDv2), the upstream interface is set to
(S,*)exclude mode for all sources S seen in traffic of the peering links. That source-specific signaling prevents forwarding of duplicate traffic throughout the access network ✨ - SSM: In the presence of Source-Specific Multicast, the proxy subscribes on its uplink interface only to those
(S,G)channels that do not arrive via the peering links 🎀
MLD proxies install data-driven timers (source-timeout) for each source, but common to all peering interfaces, to detect interruptions of data services from individual sources at proxy peers 🕰️ Termination of source-specific flows may be application specific, but it may also be due to a source handover or a transmission failure. After a handover, a mobile source may reattach at another MLD proxy with a peering relation to the listener, or at a proxy that does not peer. In the first case, traffic reappears on another peering link. In the second case, data can only be retrieved via the regular upstream 😭 To account for that latter case, the MLD proxy revokes the source-specific filter(s) at its upstream interface after the source-timeout expires (default: 50 ms). Corresponding traffic is then pulled from the regular upstream interface. Source-specific filters MUST be reinstalled whenever traffic of this source arrives at any peering interface 🔁
There is a noteworthy trade-off between traffic minimization and available traffic at the upstream that is locally filtered at the proxy. Implementors can use this relation to optimize for service-specific requirements 💖
In proceeding this way, multicast group data arrives from peering interfaces first, while only peer-wise unavailable traffic is retrieved from the regular upstream interface 🌈
6. Security Considerations 💀
Okay bestie, this is the serious part, so pay attention 👀 This document defines multicast sender mobility based on PMIPv6 and common multicast routing protocols. Consequently, threats identified as security concerns in [RFC2236], [RFC2710], [RFC3810], [RFC4605], [RFC5213], and [RFC5844] are inherited by this document.
In addition, particular attention should be paid to the implications of combining multicast and mobility management at network entities 😬 As this specification allows mobile nodes to initiate the creation of multicast forwarding states at MAGs and LMAs while changing attachments, there are threats of resource exhaustion at PMIP routers and access networks. These arise from rapid state changes, as well as from high-volume data streams routed into access networks of limited capacities 📉 In cases of PIM-SM deployment, handover operations of the MNs include re-registering sources at the Rendezvous Points at possibly high frequency. In addition to proper authorization checks of MNs, rate controls at routing agents and replicators may be needed to protect the agents and the downstream networks 🚧 In particular, MLD proxy implementations at MAGs SHOULD automatically erase multicast state on the departure of MNs, as mobile multicast listeners in the PMIPv6 domain will in general not actively terminate group membership prior to departure 🧹
The deployment of IGMP/MLD proxies for multicast routing requires particular care, as routing loops on the upstream are not automatically detected 🌀 Peering functions between proxies extend this threat in the following way. Routing loops among peering and upstream interfaces are prevented by filters on local sources. Such filtering can fail whenever prefix configurations for downstream interfaces at a proxy are incorrect or inconsistent. Consequently, implementations of peering-enabled proxies SHOULD take particular care on keeping IP configurations consistent at the downstream in a reliable and timely manner 💅 (See [RFC6224] for requirements on PMIPv6-compliant implementations of MLD proxies.)
7. Acknowledgements 🫶
The authors would like to thank (in alphabetical order) David Black, Luis M. Contreras, Spencer Dawkins, Muhamma Omer Farooq, Bohao Feng, Sri Gundavelli, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li, Cong Liu, Radia Perlman, Akbar Rahman, Behcet Sarikaya, Stig Venaas, Li-Li Wang, Sebastian Woelke, Qian Wu, and Zhi-Wei Yan for advice, help, and reviews of the document. Funding by the German Federal Ministry of Education and Research within the G-LAB Initiative (projects HAMcast, Mindstone, and SAFEST) is gratefully acknowledged. 🌸
8. References 📚
8.1. Normative References
Okay, these are the must-read refs, bestie 📚✨ Here they are, verbatim:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[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.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.8.2. Informative References
These ones are the extra reading for the curious 🧚🌸
[MULTI-EXT]
Schmidt, T., Ed., Waehlisch, M., Koodli, R., Fairhurst,
G., and D. Liu, "Multicast Listener Extensions for MIPv6
and PMIPv6 Fast Handovers", Work in Progress, May 2014.
[PEERING-ANALYSIS]
Schmidt, TC., Woelke, S., and M. Waehlisch, "Peer my Proxy
- A Performance Study of Peering Extensions for Multicast
in Proxy Mobile IP Domains", Proc. of 7th IFIP Wireless
and Mobile Networking Conference (WMNC 2014), IEEE Press,
May 2014.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[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.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013.
[RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile
IPv6 (PMIPv6) Multicast Handover Optimization by the
Subscription Information Acquisition through the LMA
(SIAL)", RFC 7161, March 2014.Appendix A. Multiple Upstream Interface Proxy ✨
Here's the bonus upstream stuff we cooked up while working on this doc 🔥 Instead of stacking multiple proxy instances on one MAG (see Section 3), you can just give a single MLD proxy multiple upstream interfaces 💅 In a typical PMIPv6 setup, each upstream interface on that one proxy can hook up to one of the LMAs. With that much choice, the proxy MUST be given forwarding rules that do two things:
- unambiguously guide traffic forwarding from directly attached mobile sources, and
- lead listener reports to initiating unique traffic subscriptions.
You can get this done with a full set of source- and group-specific filter rules (e.g., (S,*), (*,G)) installed on the proxy interfaces. These filters MAY be partly derived from PMIPv6 routing policies, and they can include a default behavior (e.g., (*,*)) 🌈
A.1. Operations for Local Multicast Sources
Okay so, packets from a locally attached multicast source get forwarded to every downstream interface with the right subscriptions, and they also go up the interface with the matching source-specific filter 🦋
Usually, the upstream interface for a mobile multicast source gets picked by policy routing (for example, the MAG-LMA tunnel interface for LMA-based routing, or the interface toward the multicast router for direct routing), but alternate configurations MAY be applied 💖 Either way, packets from a locally attached multicast source go to the matching upstream interface with the matching source-specific filter, and also to all the downstream interfaces with the right subscriptions. Main character energy 👑
A.2. Operations for Local Multicast Subscribers
The MLD proxy group-wise aggregates listener reports 🍓 The aggregated report then gets sent up the upstream interface with a matching group/channel-specific filter. The upstream interface picked for those aggregated group membership reports MAY also depend on administrative scoping rules for scoped multicast group addresses 🫶
Here's the detailed version. A Multiple Upstream Interface proxy provides and maintains a Multicast Subscription Filter Table that maps source- and group-specific filters to upstream interfaces 🧚 The forwarding decision for an aggregated MLD listener report is based on the first matching entry in that table. Two things to keep in mind. First, for IGMPv3/MLDv2, the MLD proxy does a state decomposition when needed. That means a (,G) subscription gets split into (S,G) and (* \ S,G) when there's a (,G) after (S,G) interface entries. Second, (S,*)-filters are always false when there's no source-specific signaling, which is to say in IGMPv2/MLDv1-only domains 🙈
In typical deployments, specific group services (channels) are usually either:
- associated with selected uplinks to remote LMAs, while a (,) default subscription entry (in the last table line) is bound to a local routing interface, or
- configured as local services first, while a (,) default entry (in the last table line) points to a remote uplink that provides the general multicast support.
Appendix B. Implementation 🎀
There's an implementation of the extended IGMP/MLD proxy from the MCPROXY project (http://mcproxy.realmv6.org/) 💜 It's open-source software written in C++ that uses the forwarding capabilities of the Linux kernel. It supports all the regular operations according to [RFC4605], and it allows multiple proxy instances on one node, dynamically changing downstream links, proxy-to-proxy peerings, and multiple upstream links with individual configurations. You can download the software from GitHub at https://github.com/mcproxy/mcproxy. Based on this software, an experimental performance evaluation of the proxy peering function has been reported in [PEERING-ANALYSIS] 🔥
Authors' Addresses
Thomas C. Schmidt (editor)
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Shuai Gao
Beijing Jiaotong University
Beijing
China
EMail: shgao@bjtu.edu.cn
Hong-Ke Zhang
Beijing Jiaotong University
Beijing
China
EMail: hkzhang@bjtu.edu.cn
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
EMail: mw@link-lab.net📦 where this page comes from
- ietf: rfc7287 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms