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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/