diff options
Diffstat (limited to 'doc/rfc/rfc6224.txt')
| -rw-r--r-- | doc/rfc/rfc6224.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc6224.txt b/doc/rfc/rfc6224.txt new file mode 100644 index 0000000..4006851 --- /dev/null +++ b/doc/rfc/rfc6224.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Schmidt +Request for Comments: 6224 HAW Hamburg +Category: Informational M. Waehlisch +ISSN: 2070-1721 link-lab & FU Berlin + S. Krishnan + Ericsson + April 2011 + + + Base Deployment for Multicast Listener Support + in Proxy Mobile IPv6 (PMIPv6) Domains + +Abstract + + This document describes deployment options for activating multicast + listener functions in Proxy Mobile IPv6 domains without modifying + mobility and multicast protocol standards. Similar to home agents in + Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as + multicast subscription anchor points, while Mobile Access Gateways + provide Multicast Listener Discovery (MLD) proxy functions. In this + scenario, mobile nodes remain agnostic of multicast mobility + operations. Support for mobile multicast senders is outside the + scope of this document. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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/rfc6224. + + + + + + + + + + + + +Schmidt, et al. Informational [Page 1] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + +Copyright Notice + + Copyright (c) 2011 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8 + 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8 + 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10 + 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 + 4.6. Multicast Availability throughout the Access Network . . . 12 + 4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12 + 5. Message Source and Destination Address . . . . . . . . . . . . 13 + 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 16 + Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16 + Appendix C. Comparative Evaluation of Different Approaches . . . 17 + + + + + + + + + + + + +Schmidt, et al. Informational [Page 2] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + +1. Introduction + + Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) + [RFC3775] 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 the + Local Mobility Anchor (LMA) and Mobile Access Gateways (MAGs), are + responsible for managing IP mobility on behalf of the mobile node + (MN). + + With these entities in place, the mobile node experiences an + exceptional access topology towards the static Internet in the sense + that the MAG introduces a routing hop in situations where the LMA + architecturally acts as the next hop (or designated) router for the + MN. In the particular case of multicast communication, group + membership management, as signaled by the Multicast Listener + Discovery (MLD) protocol [RFC3810] [RFC2710], requires dedicated + treatment at the network side. + + Multicast routing functions need to be placed carefully within the + PMIPv6 domain in order to augment unicast transmission with group + communication services. [RFC5213] does not explicitly address + multicast communication. Bidirectional home tunneling, the minimal + multicast support arranged by MIPv6, cannot be directly transferred + to network-based management scenarios, since a mobility-unaware node + will not initiate such a tunnel after movement. Consequently, even + minimal multicast listener support in PMIPv6 domains requires an + explicit deployment of additional functions. + + This document describes options for deploying multicast listener + functions in Proxy Mobile IPv6 domains without modifying mobility and + multicast protocol standards. Similar to home agents in Mobile IPv6, + PMIPv6 Local Mobility Anchors serve as multicast subscription anchor + points, while Mobile Access Gateways provide MLD proxy functions. In + this scenario, mobile nodes remain agnostic of multicast mobility + operations. This document does not address specific optimizations + and efficiency improvements of multicast routing for network-based + mobility discussed in [RFC5757], as such solutions would require + changes to the base PMIPv6 protocol [RFC5213]. Support for mobile + multicast senders is also outside the scope of this document. + +2. Terminology + + This document uses the terminology as defined for the mobility + protocols [RFC3775], [RFC5213], and [RFC5844], as well as the + multicast edge related protocols [RFC3376], [RFC3810], and [RFC4605]. + + + + + +Schmidt, et al. Informational [Page 3] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + +3. Overview + + The reference scenario for multicast deployment in Proxy Mobile IPv6 + domains is illustrated in Figure 1. Below, LMAA and MN-HNP are the + LMA Address and Mobile Node's Home Network Prefix as defined in + [RFC5213]. + + +-------------+ + | Content | + | Source | + +-------------+ + | + *** *** *** *** + * ** ** ** * + * * + * Fixed Internet * + * * + * ** ** ** * + *** *** *** *** + / \ + +----+ +----+ + |LMA1| |LMA2| Multicast Anchor + +----+ +----+ + LMAA1 | | LMAA2 + | | + \\ //\\ + \\ // \\ + \\ // \\ Unicast Tunnel + \\ // \\ + \\ // \\ + \\ // \\ + Proxy-CoA1 || || Proxy-CoA2 + +----+ +----+ + |MAG1| |MAG2| MLD Proxy + +----+ +----+ + | | | + MN-HNP1 | | MN-HNP2 | MN-HNP3 + MN1 MN2 MN3 + + Figure 1: Reference Network for Multicast Deployment in PMIPv6 + + An MN in a PMIPv6 domain will decide on multicast group membership + management completely independent of its current mobility conditions. + It will submit MLD Report and Done messages, based on application + triggers, using its link-local source address and multicast + destination addresses according to [RFC3810] or [RFC2710]. These + + + + + +Schmidt, et al. Informational [Page 4] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + link-local signaling messages will arrive at the currently active MAG + via one of its downstream local (wireless) links. A multicast- + unaware MAG would simply discard these MLD messages. + + To facilitate multicast in a PMIPv6 domain, an MLD proxy function + [RFC4605] needs to be deployed on the MAG that selects the tunnel + interface corresponding to the MN's LMA for its upstream interface + (cf., Section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel + interface defines an MLD proxy domain at the MAG, and it contains all + downstream links to MNs that share this specific LMA. According to + standard proxy operations, MLD Report messages will be aggregated and + then forwarded up the tunnel interface to the MN's corresponding LMA. + + Serving as the designated multicast router or an additional MLD + proxy, the LMA will transpose any MLD message from a MAG into the + multicast routing infrastructure. Correspondingly, the LMA will + create appropriate multicast forwarding states at its tunnel + interface. Traffic of the subscribed groups will arrive at the LMA, + and the LMA will forward this traffic according to its group/source + states. In addition, the LMA will act as an MLD querier, seeing its + downstream tunnel interfaces as multicast-enabled links. + + At the MAG, MLD queries and multicast data will arrive on the + (tunnel) interface that is assigned to a group of access links as + identified by its Binding Update List (cf., Section 6.1 of + [RFC5213]). As specified for MLD proxies, the MAG will forward + multicast traffic and initiate related signaling down the appropriate + access links to the MNs. Hence, all multicast-related signaling and + the data traffic will transparently flow from the LMA to the MN on an + LMA-specific tree, which is shared among the multicast sources. + + In case of a handover, the MN (unaware of IP mobility) will not send + unsolicited MLD reports. Instead, the MAG is required to maintain + group memberships in the following way. On observing a new MN on a + downstream access link, the MAG sends a MLD General Query. Based on + its outcome and the multicast group states previously maintained at + the MAG, a corresponding Report will be sent to the LMA aggregating + group membership states according to the proxy function. Additional + Reports can be omitted when the previously established multicast + forwarding states at the new MAG already cover the subscriptions of + the MN. + + In summary, the following steps are executed on handover: + + 1. The MAG-MN link comes up and the MAG discovers the new MN. + + 2. Unicast address configuration and PMIPv6 binding are performed + after the MAG determines the corresponding LMA. + + + +Schmidt, et al. Informational [Page 5] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + 3. Following IPv6 address configuration, the MAG should send an + (early) MLD General Query to the new downstream link as part of + its standard multicast-enabled router operations. + + 4. The MAG should determine whether the MN is admissible to + multicast services; if it's not, then stop here. + + 5. The MAG adds the new downstream link to the MLD proxy instance + with up-link to the corresponding LMA. + + 6. The corresponding proxy instance triggers an MLD General Query on + the new downstream link. + + 7. The MN Membership Reports arrive at the MAG, in response either + to the early query or to the query sent by the proxy instance. + + 8. The Proxy processes the MLD Report, updates states, and reports + upstream if necessary. + + After Re-Binding, the LMA is not required to issue a MLD General + Query on the tunnel link to refresh forwarding states. Multicast + state updates should be triggered by the MAG, which aggregates + subscriptions of all its MNs (see the call flow in Figure 2). + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schmidt, et al. Informational [Page 6] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + MN1 MAG1 MN2 MAG2 LMA + | | | | | + | Join(G) | | | | + +--------------->| | | | + | | Join(G) | | | + | |<---------------+ | | + | | | | | + | | Aggregated Join(G) | | + | +================================================>| + | | | | | + | | Mcast Data | | | + | |<================================================+ + | | | | | + | Mcast Data | Mcast Data | | | + |<---------------+--------------->| | | + | | | | | + | < Movement of MN 2 to MAG2 & PMIP Binding Update > | + | | | | | + | | |--- Rtr Sol -->| | + | | |<-- Rtr Adv ---| | + | | | | | + | | | MLD Query | | + | | |<--------------+ | + | | | | | + | | | Join(G) | | + | | +-------------->| | + | | | Aggregated Join(G) + | | | +===============>| + | | | | | + | | Mcast Data | | | + | |<================================================+ + | | | | Mcast Data | + | | | |<===============+ + | Mcast Data | | | | + |<---------------+ | Mcast Data | | + | | |<--------------+ | + | | | | | + + Figure 2: Call Flow of Multicast-Enabled PMIP + with "MLD Membership Report" Abbreviated by "Join" + + These multicast deployment considerations likewise apply for mobile + nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. + PMIPv6 can provide IPv4 home address mobility support [RFC5844]. + Such mobile nodes will use IGMP [RFC2236] [RFC3376] signaling for + multicast, which is handled by an IGMP proxy function at the MAG in + an analogous way. + + + + +Schmidt, et al. Informational [Page 7] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + Following these deployment steps, multicast management transparently + interoperates with PMIPv6. It is worth noting that MNs -- while + being attached to the same MAG, but associated with different LMAs -- + can subscribe to the same multicast group. Thereby, data could be + distributed redundantly in the network and duplicate traffic could + arrive at a MAG. Additionally, in a point-to-point wireless link + model, a MAG might be forced to transmit the same data over one + wireless domain to different MNs. However, multicast traffic + arriving at one interface of the MN will always remain unique, i.e., + the mobile multicast distribution system will never cause duplicate + packets arriving at an MN (see Appendix C for further + considerations). + +4. Deployment Details + + Multicast activation in a PMIPv6 domain requires to deploy general + multicast functions at PMIPv6 routers and to define their interaction + with the PMIPv6 protocol in the following way. + +4.1. Operations of the Mobile Node + + A mobile node willing to manage multicast traffic will join, + maintain, and leave groups as if located in the fixed Internet. No + specific mobility actions nor implementations are required at the MN. + +4.2. Operations of the Mobile Access Gateway + + A Mobile Access Gateway is required to assist in MLD signaling and + data forwarding between the MNs that it serves and the corresponding + LMAs associated to each MN. It therefore needs to implement an + instance of the MLD proxy function [RFC4605] for each upstream tunnel + interface that has been established with an LMA. The MAG decides on + the mapping of downstream links to a proxy instance (and hence an + upstream link to an LMA) based on the regular Binding Update List as + maintained by PMIPv6 standard operations (cf., Section 6.1 of + [RFC5213]). As links connecting MNs and MAGs change under mobility, + MLD proxies at MAGs must be able to dynamically add and remove + downstream interfaces in their configurations. + + On the reception of MLD reports from an MN, the MAG must identify the + corresponding proxy instance from the incoming interface and perform + regular MLD proxy operations: it will insert/update/remove multicast + forwarding state on the incoming interface and will merge state + updates into the MLD proxy membership database. It will then send an + aggregated Report via the upstream tunnel to the LMA when the + membership database (cf., Section 4.1 of [RFC4605]) changes. + Conversely, on the reception of MLD queries, the MAG proxy instance + will answer the Queries on behalf of all active downstream receivers + + + +Schmidt, et al. Informational [Page 8] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + maintained in its membership database. Queries sent by the LMA do + not force the MAG to trigger corresponding messages immediately + towards MNs. Multicast traffic arriving at the MAG on an upstream + interface will be forwarded according to the group-specific or + source-specific forwarding states as acquired for each downstream + interface within the MLD proxy instance. At this stage, it is + important to note that IGMP/MLD proxy implementations capable of + multiple instances are expected to closely follow the specifications + of Section 4.2 in [RFC4605], i.e., treat proxy instances in isolation + of each other while forwarding. In providing isolated proxy + instances, the MAG will uniquely serve its downstream links with + exactly the data that belong to whatever group is subscribed on the + particular interface. + + After a handover, the MAG will continue to manage upstream tunnels + and downstream interfaces as specified in the PMIPv6 specification. + It must dynamically associate new access links to proxy instances + that include the upstream connection to the corresponding LMA. The + MAG detects the arrival of a new MN by receiving a router + solicitation message and by an upcoming link. To learn about + multicast groups subscribed by a newly attaching MN, the MAG should + send a General Query to the MN's link. Querying an upcoming + interface is a standard operation of MLD queriers (see Appendix A) + and is performed immediately after address configuration. In + addition, an MLD query should be initiated by the proxy instance, as + soon as a new interface has been configured for downstream. In case + the access link between MN and MAG goes down, interface-specific + multicast states change. Both cases may alter the composition of the + membership database and this will trigger corresponding Reports + towards the LMA. Note that the actual observable state depends on + the access link model in use. + + An MN may be unable to answer MAG multicast membership queries due to + handover procedures, or its report may arrive before the MAG has + configured its link as the proxy downstream interface. Such + occurrences are equivalent to a General Query loss. To prevent + erroneous query timeouts at the MAG, MLD parameters should be + carefully adjusted to the mobility regime. In particular, MLD timers + and the Robustness Variable (see Section 9 of [RFC3810]) should be + chosen to be compliant with the time scale of handover operations and + proxy configurations in the PMIPv6 domain. + + In proceeding this way, the MAG is able to aggregate multicast + subscriptions for each of its MLD proxy instances. However, this + deployment approach does not prevent multiple identical streams + arriving from different LMA upstream interfaces. Furthermore, a + multipoint channel forwarding into the wireless domain is prevented + by the point-to-point link model in use. + + + +Schmidt, et al. Informational [Page 9] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + +4.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 querier for the + corresponding MAG. It implements the function of the designated + multicast router or a further MLD proxy. According to MLD reports + received from a MAG (on behalf of the MNs), the LMA establishes/ + maintains/removes group-/source-specific multicast forwarding states + at its corresponding downstream tunnel interfaces. At the same time, + it procures for aggregated multicast membership maintenance at its + upstream interface. Based on the multicast-transparent operations of + the MAGs, the LMA treats its tunnel interfaces as multicast-enabled + downstream links, serving zero to many listening nodes. Multicast + traffic arriving at the LMA is transparently forwarded according to + its multicast forwarding information base. + + After a handover, the LMA will receive Binding De-Registrations and + Binding Lifetime Extensions that will cause a re-mapping of home + network prefix(es) to a new Proxy-CoA in its Binding Cache (see + Section 5.3 of [RFC5213]). The multicast forwarding states require + updating, as well, if the MN within an MLD proxy domain is the only + receiver of a multicast group. Two different cases need to be + considered: + + 1. The mobile node is the only receiver of a group behind the + interface at which a De-Registration was received: the membership + database of the MAG changes, which will trigger a Report/Done + sent via the MAG-to-LMA interface to remove this group. The LMA + thus terminates multicast forwarding. + + 2. The mobile node is the only receiver of a group behind the + interface at which a Lifetime Extension was received: the + membership database of the MAG changes, which will trigger a + Report sent via the MAG-to-LMA interface to add this group. The + LMA thus starts multicast distribution. + + In proceeding this way, each LMA will provide transparent multicast + support for the group of MNs it serves. It will perform traffic + aggregation at the MN-group level and will assure that multicast data + streams are uniquely forwarded per individual LMA-to-MAG tunnel. + +4.4. IPv4 Support + + An MN in a PMIPv6 domain may use an IPv4 address transparently for + communication as specified in [RFC5844]. For this purpose, LMAs can + register IPv4-Proxy-CoAs in its Binding Caches, and MAGs can provide + IPv4 support in access networks. Correspondingly, multicast + membership management will be performed by the MN using IGMP. For + + + +Schmidt, et al. Informational [Page 10] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + 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 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. + + A particular note is worth giving the scenario of [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. + + MLD/IGMP signaling between MNs and the MAG is on point-to-point links + (identical to unicast). Aggregated MLD/IGMP signaling between the + MAG proxy instance and the LMA remains link-local between the routers + and independent of any individual MN. So the MAG-proxy and the LMA + should not use GRE key identifiers, but plain GRE to exchange MLD + queries and reports. Similarly, multicast traffic sent from an LMA + to MAGs proceeds as router-to-router forwarding according to the + multicast forwarding information base (MFIB) of the LMA and + independent of MN's unicast addresses, while the MAG proxy instance + distributes multicast data down the point-to-point links (interfaces) + according to its own MFIB, independent of MN's IP addresses. + + It remains an open issue how communication proceeds in a multi- + operator scenario, i.e., from which network the LMA pulls multicast + traffic. This could be any mobility Operator itself, or a third + party. However, this backbone routing in general is out of scope of + the document, and most likely a matter of contracts. + +4.5. Multihoming Support + + An MN can connect to a PMIPv6 domain through multiple interfaces and + experience transparent unicast handovers at all interfaces (cf., + Section 5.4 of [RFC5213]). In such simultaneous access scenarios, it + can autonomously assign multicast channel subscriptions to individual + interfaces (see [RFC5757] for additional details). While doing so, + + + +Schmidt, et al. Informational [Page 11] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + multicast mobility operations described in this document will + transparently preserve the association of channels to interfaces in + the following way. + + Multicast listener states are kept per interface in the MLD state + table. An MN will answer to an MLD General Query received on a + specific (re-attaching) interface according to the specific + interface's state table. Thereafter, multicast forwarding is resumed + for channels identical to those under subscription prior to handover. + Consequently, an MN in a PMIPv6 domain may use multiple interfaces to + facilitate load balancing or redundancy, but cannot follow a 'make- + before-break' approach to service continuation on handovers. + +4.6. Multicast Availability throughout the Access Network + + There may be deployment scenarios where multicast services are + available throughout the access network, independent of the PMIPv6 + infrastructure. Direct multicast access at MAGs may be supported + through native multicast routing within a flat access network that + includes a multicast router, via dedicated (tunnel or VPN) links + between MAGs and designated multicast routers, or by deploying + Automatic Multicast Tunneling (AMT) [AUTO-MULTICAST]. + + Multicast deployment can be simplified in these scenarios. A single + proxy instance at MAGs with up-link to the multicast cloud, for + instance, could serve group communication purposes. MAGs could + operate as general multicast routers or AMT gateways as well. + + Common to these solutions is that mobility management is covered by + the dynamics of multicast routing, as initially foreseen in the + Remote Subscription approach, i.e., join via a local multicast router + as sketched in [RFC3775]. Care must be taken to avoid avalanche + problems or service disruptions due to tardy multicast routing + operations and to adapt to different link-layer technologies + [RFC5757]. The different possible approaches should be carefully + investigated beyond the initial sketch in Appendix C. Such work is + beyond the scope of this document. + +4.7. A Note on Explicit Tracking + + An IGMPv3/MLDv2 Querier may operate in combination with explicit + tracking as described in Appendix A.2 of [RFC3376], or Appendix A.2 + of [RFC3810]. This mechanism allows routers to monitor each + multicast receiver individually. Even though this procedure is not + standardized yet, it is widely implemented by vendors as it supports + faster leave latencies and reduced signaling. + + + + + +Schmidt, et al. Informational [Page 12] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + Enabling explicit tracking on downstream interfaces of the LMA and + MAG would track a single MAG and MN respectively per interface. It + may be used to preserve bandwidth on the MAG-MN link. + +5. Message Source and Destination Address + + This section describes source and destination addresses of MLD + messages and encapsulating outer headers when deployed in the PMIPv6 + domain. This overview is for clarification purposes only and does + not define a behavior different from referenced standards in any way. + + The interface identifier A-B denotes an interface on node A, which is + connected to node B. This includes tunnel interfaces. Destination + addresses for MLD/IGMP messages shall be as specified in Section 8 of + [RFC2710] for MLDv1, and Sections 5.1.15 and 5.2.14 of [RFC3810] for + MLDv2. + +5.1. Query + + +===========+================+======================+==========+ + | Interface | Source Address | Destination Address | Header | + +===========+================+======================+==========+ + | | LMAA | Proxy-CoA | outer | + + LMA-MAG +----------------+----------------------+----------+ + | | LMA-link-local | [RFC2710], [RFC3810] | inner | + +-----------+----------------+----------------------+----------+ + | MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- | + +-----------+----------------+----------------------+----------+ + +5.2. Report/Done + + +===========+================+======================+==========+ + | Interface | Source Address | Destination Address | Header | + +===========+================+======================+==========+ + | MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- | + +-----------+----------------+----------------------+----------+ + | | Proxy-CoA | LMAA | outer | + + MAG-LMA +----------------+----------------------+----------+ + | | MAG-link-local | [RFC2710], [RFC3810] | inner | + +-----------+----------------+----------------------+----------+ + +6. Security Considerations + + This document does not introduce additional messages or novel + protocol operations. Consequently, no additional threats are + introduced by this document beyond those identified as security + concerns of [RFC3810], [RFC4605], [RFC5213], and [RFC5844]. + + + + +Schmidt, et al. Informational [Page 13] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + However, 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 arrive from rapid state changes, as well as from + high-volume data streams routed into access networks of limited + capacities. In addition to proper authorization checks of MNs, rate + controls at replicators may be required to protect the agents and the + downstream networks. In particular, MLD proxy implementations at + MAGs should carefully procure automatic multicast state extinction on + the departure of MNs, as mobile multicast listeners in the PMIPv6 + domain will not actively terminate group membership prior to + departure. + +7. Acknowledgements + + This memo follows initial requirements work presented in "Multicast + Support Requirements for Proxy Mobile IPv6" (July 2009), and is the + outcome of extensive previous discussions and a follow-up of several + initial documents on the subject. The authors would like to thank + (in alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley, + Gorry Fairhurst, Dirk von Hugo, Liu Hui, Seil Jeon, Jouni Korhonen, + Guang Lu, Sebastian Meiling, Akbar Rahman, Imed Romdhani, Behcet + Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for + advice, help, and reviews of the document. Funding by the German + Federal Ministry of Education and Research within the G-LAB + Initiative is gratefully acknowledged. + +8. References + +8.1. Normative References + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, + October 1999. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. + + [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support + in IPv6", RFC 3775, June 2004. + + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + + + + +Schmidt, et al. Informational [Page 14] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, + "Internet Group Management Protocol (IGMP) / Multicast + Listener Discovery (MLD)-Based Multicast Forwarding + ("IGMP/MLD Proxying")", RFC 4605, August 2006. + + [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., + and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. + + [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy + Mobile IPv6", RFC 5844, May 2010. + +8.2. Informative References + + [AUTO-MULTICAST] + Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. + Pusateri, "Automatic IP Multicast Without Explicit Tunnels + (AMT)", Work in Progress, March 2010. + + [RFC2236] Fenner, W., "Internet Group Management Protocol, Version + 2", RFC 2236, November 1997. + + [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast + Mobility in Mobile IP Version 6 (MIPv6): Problem Statement + and Brief Survey", RFC 5757, February 2010. + + [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, + "Generic Routing Encapsulation (GRE) Key Option for Proxy + Mobile IPv6", RFC 5845, June 2010. + + + + + + + + + + + + + + + + + + + + + + + +Schmidt, et al. Informational [Page 15] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + +Appendix A. Initial MLD Queries on Upcoming Links + + According to [RFC3810] and [RFC2710], when an IGMP-/MLD-enabled + multicast router starts operating on a subnet, by default it + considers itself as querier and sends several General Queries. Such + initial query should be sent by the router immediately, but could be + delayed by a (tunable) Startup Query Interval (see Sections 7.6.2 and + 9.6 of [RFC3810]). + + Experimental tests on Linux and Cisco systems have revealed immediate + IGMP Queries followed a link trigger event (within a fraction of 1 + ms), while MLD queries immediately followed the autoconfiguration of + IPv6 link-local addresses at the corresponding interface. + +Appendix B. State of IGMP/MLD Proxy Implementations + + The deployment scenario defined in this document requires certain + proxy functionalities at the MAGs that implementations of [RFC4605] + need to contribute. In particular, a simultaneous support of IGMP + and MLD is needed, as well as a configurable list of downstream + interfaces that may be altered during runtime, and the deployment of + multiple proxy instances at a single router that can operate + independently on separated interfaces. + + A brief experimental trial undertaken in February 2010 revealed the + following divergent statuses of selected IGMP/MLD proxy + implementations. + + Cisco Edge Router: Software-based commodity edge routers (test + device from the 26xx-Series) implement IGMPv2/v3 proxy functions + only in combination with Protocol Independent Multicast - Sparse + Mode (PIM-SM). There is no support of MLD proxy. Interfaces are + dynamically configurable at runtime via the command line + interface, but multiple proxy instances are not supported. + + Linux igmpproxy: IGMPv2 Proxy implementation that permits a static + configuration of downstream interfaces (simple bug fix required). + Multiple instances are prevented by a lock (corresponding code + reused from a previous Distance Vector Multicast Routing Protocol + (DVMRP) implementation). IPv6/MLD is unsupported. Project page: + http://sourceforge.net/projects/igmpproxy/. + + Linux gproxy: IGMPv3 Proxy implementation that permits configuration + of the upstream interface, only. Downstream interfaces are + collected at startup without dynamic extension of this list. No + support of multiple instances or MLD. + + + + + +Schmidt, et al. Informational [Page 16] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + Linux ecmh: MLDv1/2 Proxy implementation without IGMP support that + inspects IPv4 tunnels and detects encapsulated MLD messages. + Allows for dynamic addition of interfaces at runtime and multiple + instances. However, downstream interfaces cannot be configured. + Project page: http://sourceforge.net/projects/ecmh/ + +Appendix C. Comparative Evaluation of Different Approaches + + In this section, we briefly evaluate two orthogonal PMIP concepts for + multicast traffic organization at LMAs. In scenario A, multicast is + provided by combined unicast/multicast LMAs as described in this + document. Scenario B directs traffic via a dedicated, central + multicast router ("LMA-M") that tunnels packets to MAGs independent + of unicast handoffs. + + Neither approach establishes native multicast distribution between + the LMA and MAG; instead, they use tunneling mechanisms. In scenario + A, a MAG is connected to different multicast-enabled LMAs and can + receive the same multicast stream via multiple paths depending on the + group subscriptions of MNs and their associated LMAs. This problem, + a.k.a. the tunnel convergence problem, may lead to redundant traffic + at the MAGs. In contrast, scenario B configures MAGs to establish a + tunnel to a single, dedicated multicast LMA for all attached MNs and + relocates overhead costs to the multicast anchor. This eliminates + redundant traffic but may result in an avalanche problem at the LMA. + + We quantify the costs of both approaches based on two metrics: the + amount of redundant traffic at MAGs and the number of simultaneous + streams at LMAs. Realistic values depend on the topology and the + group subscription model. To explore scalability in a large PMIP + domain of 1,000,000 MNs, we consider the following two extreme + multicast settings. + + 1. All MNs participate in distinct multicast groups. + + 2. All MNs join the same multicast group. + + A typical PMIP deployment approximately allows for 5,000 MNs attached + to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000 + MNs require approximately 200 MAGs backed by 4 LMAs for unicast + transmission. In scenario A, these LMAs also forward multicast + streams, while in scenario B one additional dedicated LMA (LMA-M) + serves multicast. In the following, we calculate the metrics + described above. In addition, we display the number of packet + streams that cross the interconnecting (wired) network within a + PMIPv6 domain. + + + + + +Schmidt, et al. Informational [Page 17] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + + Setting 1: + +===================+==============+================+===============+ + | PMIP multicast | # of redund. | # of simul. | # of total | + | scheme | streams | streams | streams in | + | | at MAG | at LMA/LMA-M | the network | + +===================+==============+================+===============+ + | Combined Unicast/ | 0 | 250,000 | 1,000,000 | + | Multicast LMA | | | | + +-------------------+--------------+----------------+---------------+ + | Dedicated | 0 | 1,000,000 | 1,000,000 | + | Multicast LMA | | | | + +-------------------+--------------+----------------+---------------+ + + 1,000,000 MNs are subscribed to distinct multicast groups. + + Setting 2: + +===================+==============+================+===============+ + | PMIP multicast | # of redund. | # of simul. | # of total | + | scheme | streams | streams | streams in | + | | at MAG | at LMA/LMA-M | the network | + +===================+==============+================+===============+ + | Combined Unicast/ | 3 | 200 | 800 | + | Multicast LMA | | | | + +-------------------+--------------+----------------+---------------+ + | Dedicated | 0 | 200 | 200 | + | Multicast LMA | | | | + +-------------------+--------------+----------------+---------------+ + + 1,000,000 MNs are subscribed to the same multicast group. + + These considerations of extreme settings show that packet duplication + and replication effects apply in changing intensities for different + use cases of multicast data services. However, tunnel convergence, + i.e., duplicate data arriving at a MAG, does cause much smaller + problems in scalability than the stream replication at LMAs + (avalanche problem). For scenario A, it should also be noted that + the high stream replication requirements at LMAs in setting 1 can be + attenuated by deploying additional LMAs in a PMIP domain, while + scenario B does not allow for distributing the LMA-M, as no handover + management is available at LMA-M. + + + + + + + + + + + +Schmidt, et al. Informational [Page 18] + +RFC 6224 Multicast Listeners in PMIPv6 April 2011 + + +Authors' Addresses + + Thomas C. Schmidt + HAW Hamburg + Berliner Tor 7 + Hamburg 20099 + Germany + + EMail: schmidt@informatik.haw-hamburg.de + URI: http://inet.cpt.haw-hamburg.de/members/schmidt + + + Matthias Waehlisch + link-lab & FU Berlin + Hoenower Str. 35 + Berlin 10318 + Germany + + EMail: mw@link-lab.net + + + Suresh Krishnan + Ericsson + 8400 Decarie Blvd. + Town of Mount Royal, QC + Canada + + EMail: suresh.krishnan@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + +Schmidt, et al. Informational [Page 19] + |