Internet Engineering Task Force (IETF) T. Schmidt, Ed. Request for Comments: 7287 HAW Hamburg Category: Experimental S. Gao ISSN: 2070-1721 H. Zhang Beijing Jiaotong University M. Waehlisch link-lab & FU Berlin June 2014 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
AbstractMulticast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7287.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . 27
RFC5213] extends Mobile IPv6 (MIPv6) [RFC6275] by network-based management functions that enable IP mobility for a host without requiring its participation in any mobility-related signaling. Additional network entities called Local Mobility Anchor (LMAs) and Mobile Access Gateways (MAGs) are responsible for managing IP mobility on behalf of the mobile node (MN). An MN connected to a PMIPv6 domain, which only operates according to the base specifications of [RFC5213], cannot participate in multicast communication, as MAGs will discard group packets. Multicast support for mobile listeners can be enabled within a PMIPv6 domain by deploying MLD proxy functions at Mobile Access Gateways, and multicast routing functions at Local Mobility Anchors [RFC6224]. This base deployment option is the simplest way to PMIPv6 multicast extensions in the sense that it follows the common PMIPv6 traffic model and neither requires new protocol operations nor additional infrastructure entities. Standard software functions need to be activated on PMIPv6 entities, only, at the price of possibly non- optimal multicast routing. Alternate solutions leverage performance optimization by providing multicast routing at the access gateways directly [MULTI-EXT] or by using selective route optimization schemes [RFC7028]. Such approaches (partially) follow the model of providing multicast data services in parallel to PMIPv6 unicast routing [RFC7161]. Multicast listener support satisfies the needs of receptive use cases such as IPTV or server-centric gaming on mobiles. However, current trends in the Internet develop towards user-centric, highly interactive group applications like user-generated streaming, conferencing, collective mobile sensing, etc. Many of these popular applications create group content at end systems and can largely profit from a direct data transmission to a multicast-enabled network. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for the base deployment scenario [RFC6224], for direct traffic distribution within an ISP's access network, as well as for selective route optimization schemes. The source mobility problem as discussed in [RFC5757] serves as a foundation of this document. Mobile nodes in this setting remain agnostic of multicast mobility operations.
RFC6275], [RFC5213], and [RFC5844], as well as the multicast routing [RFC4601] and edge-related protocols [RFC3376], [RFC3810], and [RFC4605]. Throughout this document, we use the following 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]. RFC2119]. Figure 1. It displays the general setting for source mobility -- mobile nodes (MNs) with Home Network Prefixes (HNPs) that receive services via tunnels, which are spanned between a Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address (Proxy-CoA) at a Mobility Access Gateway (MAG). MAGs play the role of first-hop access routers that serve multiple MNs on the downstream while running 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 An MN in a PMIPv6 domain will decide on multicast data transmission completely independent of its current mobility conditions. It will send packets as initiated by applications, using its source address with an HNP and a multicast destination address chosen by application needs. Multicast packets will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast-unaware MAG would simply discard these packets in the absence of instructions for packet processing, i.e., a Multicast Routing Information Base (MRIB).
An MN can successfully distribute multicast data in PMIPv6, if MLD proxy functions are deployed at the MAG as described in [RFC6224]. In this setup, the MLD proxy instance serving a mobile multicast source has configured its upstream interface at the tunnel towards the MN's corresponding LMA. For each LMA, there will be a separate instance of an MLD proxy. According to the specifications given in [RFC4605], multicast data arriving from a downstream interface of an MLD proxy will be forwarded to the upstream interface and to all but the incoming downstream interfaces that have appropriate forwarding states for this group. Thus, multicast streams originating from an MN will arrive at the corresponding LMA and directly at all mobile receivers co-located at the same MAG and MLD proxy instance. Serving as the designated multicast router or an additional MLD proxy, the LMA forwards data to the fixed Internet, whenever forwarding states are maintained by multicast routing. If the LMA is acting as another MLD proxy, it will forward the multicast data to its upstream interface and to downstream interfaces with matching subscriptions, accordingly. In case of a handover, the MN (being unaware of IP mobility) can continue to send multicast packets as soon as network connectivity is re-established. At this time, the MAG has determined the corresponding LMA, and IPv6 unicast address configuration (including PMIPv6 bindings) has been completed. Still, multicast packets arriving at the MAG are discarded (if not buffered) until the MAG has completed the following steps. 1. The MAG has determined that the MN is admissible to multicast services. 2. The MAG has added the new downstream link to the MLD proxy instance with an uplink to the corresponding LMA. As soon as the MN's uplink is associated with the corresponding MLD proxy instance, multicast packets are forwarded again to the LMA and eventually to receivers within the PMIP domain. (See the call flow in Figure 2.) In this way, multicast source mobility is transparently enabled in PMIPv6 domains that deploy the base scenario for multicast.
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 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]. IPv4 multicast is handled by an IGMP proxy function at the MAG in an analogous way. Following these deployment steps, multicast traffic distribution transparently interoperates with PMIPv6. It is worth noting that an MN -- while being attached to the same MAG as the mobile source, but associated with a different LMA -- cannot receive multicast traffic on a shortest path. Instead, multicast streams flow up to the LMA of
the mobile source, are transferred to the LMA of the mobile listener, and are tunneled downwards to the MAG again. (See Section 5 for further optimizations.) RFC6224]). On the arrival of an MN, the MAG decides on the mapping of downstream links to a proxy instance and the upstream link to the LMA based on the regular Binding Update List as maintained by PMIPv6 standard operations. When multicast data is received from the MN, the MAG MUST identify the corresponding proxy instance from the incoming interface and forwards multicast data upstream according to [RFC4605]. The MAG MAY apply special admission control to enable multicast data transmission from an MN. It is advisable to take special care that MLD proxy implementations do not redistribute multicast data to downstream interfaces without appropriate subscriptions in place.
RFC4601] will require sources to be directly connected for sending PIM registers to the Rendezvous Point (RP). This does not hold in a PMIPv6 domain, as MAGs are routers intermediate to the MN and the LMA. In this sense, MNs are multicast sources external to the PIM-SM domain. To mitigate this incompatibility common to all subsidiary MLD proxy domains, the LMA MUST act as a PIM Border Router and activate the Border-bit. In this case, the DirectlyConnected(S) is treated as being TRUE for mobile sources and the PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be TRUE, as 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] ). In addition, an LMA serving as the PIM Designated Router (DR) is connected to MLD proxies via individual IP tunnel interfaces and will 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. 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.
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. 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.) 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 MAGs Figure 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. 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 that 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) that 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. Section 188.8.131.52. 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 184.108.40.206). This problem can be mitigated by aggregating proxies on a lower layer.
Figure 3(b)). Throughout this section, it is assumed that the PMIPv6 mobility domain is part of a single PIM-SM multicast routing domain with PIM-SM routing functions present at all MAGs and all LMAs. The PIM routing instance at a MAG SHALL then serve as the Designated Router (DR) for all directly attached Mobile Nodes. For expediting handover operations, it is advisable to position PIM Rendezvous Points (RPs) in the core of the PMIPv6 network domain. However, regular IP routing tables need not be present in a PMIPv6 deployment, and additional effort is required to establish reverse path forwarding rules as required by PIM-SM. RFC4601]), the following information is needed. o 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. The setup of these general routes is expected to follow the topology of the operator network and is beyond the scope of this document. The following route entries are required at a PIM-operating MAG when phase two or three of PIM or PIM-SSM is in operation. o 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. o 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.
response, the PIM RP will recognize the known source at a new (tunnel) interface and will immediately respond with a register stop. As the RP had previously joined the shortest path tree towards the source via the LMA, it will see an RPF change when data arrives at a new interface. This is implementation dependent and can trigger an update of the PIM MRIB as well as a new PIM Join message that will install the multicast forwarding state missing at the new MAG. Otherwise, the tree is periodically updated by Joins transmitted towards the new MAG on a path via the LMA. In proceeding this way, a quick recovery of PIM transition from phase one to two will be performed per handover. Section 4.3.3) will generate proper states for a native forwarding from the new MAG via the LMA. Thereafter, packets arriving at the LMA without source register encapsulation are forwarded natively along the shortest path tree towards receivers. In consequence, the PIM transitions from phase one to two to three will be quickly recovered per handover but still lead to an enhanced signaling load and intermediate packet loss.
Section 4.3.4). However, on handover and in the absence of RP-based data distribution, SSM data delivery cannot be resumed via source registering as in PIM phase one. Consequently, data packets transmitted after a handover will be discarded at the MAG until regular tree maintenance has reestablished the (S,G) forwarding state at the new MAG.
RFC4605]) at MAGs has proven a useful and appropriate approach to multicast in PMIPv6; see [RFC6224] and [RFC7028]. However, deploying unmodified standard proxies can go along with significant performance degradation for mobile senders as discussed in this document. To overcome these deficits, an optimized approach to multicast source mobility based on extended peering functions among proxies is defined in this section. Based on such direct data exchange between proxy instances at MAGs, triangular routing is avoided and multicast streams can be disseminated directly within a PMIPv6 access network, and in particular within MAG routing machines. Prior to presenting the solution, we will summarize the relevant requirements.
RFC6224] or remotely deployed). Peerings remain as silent virtual links in regular proxy operations. Data is exchanged on such links only in cases where one peering proxy on its downstream directly connects to a source of multicast traffic to which the other peering proxy actively subscribes. In such cases, the proxy connected to the source will receive a listener report on its peering interface and will forward traffic from its local source accordingly. It is worth noting that 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].
In detail, a proxy will extract from its configuration the network prefixes attached to its downstream interfaces and MUST implement a source filter base at its peering interfaces that restricts data transmission to IP source addresses from its local prefixes. This 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 prevented from traversing any peering link, but they are only forwarded to regular downstream interfaces with appropriate subscription states. In this way, multihop forwarding on peering links is prevented. Multicast traffic arriving from a locally attached source will be forwarded to the regular upstream interface and all downstream interfaces with appropriate subscription states (i.e., regular proxy operations). In addition, multicast packets of local origin are transferred to those peering interfaces with appropriate subscription states. RFC4605] will be used only for retrieving those groups (channels) that remain unavailable from peerings. From this extension of [RFC4605], an MLD proxy with peering interconnects will exhibit several interfaces for pulling remote traffic: the regular upstream and the peerings. Traffic available from any of the peering links will be mutually disjoint but normally also available from the upstream. To prevent duplicate traffic from arriving at the listener side, the proxy o MAY delay aggregated reports to the upstream, and o 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: In the presence of ASM using IGMPv2/MLDv1, only, the proxy cannot signal source filtering to its upstream. Correspondingly, it applies (S,*) ingress filters at its upstream interface for all sources S seen in traffic on the peering links. It is noteworthy that 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. The corresponding source-specific signaling will prevent forwarding of duplicate traffic throughout the access network. SSM: In the presence of Source-Specific Multicast, the proxy will subscribe on its uplink interface to those (S,G) channels, only, that do not arrive via the peering links. MLD proxies will 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 also may 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. While 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 the latter, the MLD proxy revokes the source-specific filter(s) at its upstream interface, after the source-timeout expires (default: 50 ms). Corresponding traffic will then be 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 will arrive from peering interfaces first, while only peer-wise unavailable traffic is retrieved from the regular upstream interface.
RFC2236], [RFC2710], [RFC3810], [RFC4605], [RFC5213], and [RFC5844] are inherited by this document. In addition, particular attention should be paid to 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, threats of resource exhaustion at PMIP routers and access networks 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.)
[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. [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.
Section 3) can be avoided by adding multiple upstream interfaces to a single MLD proxy. In a typical PMIPv6 deployment, each upstream interface of a single proxy instance can interconnect to one of the LMAs. With such ambiguous upstream options, appropriate forwarding rules MUST be supplied to o unambiguously guide traffic forwarding from directly attached mobile sources, and o lead listener reports to initiating unique traffic subscriptions. This can be achieved by a complete set of source- and group-specific filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. These filters MAY be derived in part from PMIPv6 routing policies and can include a default behavior (e.g., (*,*)).
decision for an aggregated MLD listener report is based on the first matching entry from this table, with the understanding that for IGMPv3/MLDv2 the MLD proxy performs a state decomposition, if needed (i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the presence of (*,G) after (S,G) interface entries), and that (S,*)-filters are always false in the absence of source-specific signaling, i.e., in IGMPv2/MLDv1 only domains. In typical deployment scenarios, specific group services (channels) are either o 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 o 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. http://mcproxy.realmv6.org/). This open- source software is written in C++ and uses forwarding capabilities of the Linux kernel. It supports all regular operations according to [RFC4605] and allows for multiple proxy instances on one node, dynamically changing downstream links, proxy-to-proxy peerings, and multiple upstream links with individual configurations. The software can be downloaded 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].
http://inet.cpt.haw-hamburg.de/members/schmidt Shuai Gao Beijing Jiaotong University Beijing China EMail: email@example.com Hong-Ke Zhang Beijing Jiaotong University Beijing China EMail: firstname.lastname@example.org Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin 10318 Germany EMail: email@example.com