draft-ietf-multimob-pmipv6-base-solution-00.txt   draft-ietf-multimob-pmipv6-base-solution-01.txt 
MULTIMOB Group T C. Schmidt MULTIMOB Group T C. Schmidt
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: BCP M. Waehlisch Intended status: BCP M. Waehlisch
Expires: August 28, 2010 link-lab & FU Berlin Expires: November 26, 2010 link-lab & FU Berlin
S. Krishnan S. Krishnan
Ericsson Ericsson
February 24, 2010 May 25, 2010
Base Deployment for Multicast Listener Support in PMIPv6 Domains Base Deployment for Multicast Listener Support in PMIPv6 Domains
draft-ietf-multimob-pmipv6-base-solution-00 draft-ietf-multimob-pmipv6-base-solution-01
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, PMIPv6 Local Mobility Anchors serve as multicast Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
subscription anchor points, while Mobile Access Gateways provide MLD subscription anchor points, while Mobile Access Gateways provide MLD
proxy functions. In this scenario, Mobile Nodes remain agnostic of proxy functions. In this scenario, Mobile Nodes remain agnostic of
multicast mobility operations. multicast mobility operations.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 26, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 15 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 9 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 9
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multicast Availability throughout the Access Network . . . 11 4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
4.6. A Note on Explicit Tracking . . . . . . . . . . . . . . . 11 4.6. Multicast Availability throughout the Access Network . . . 11
5. Message Source and Destination Address . . . . . . . . . . . . 11 4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 12
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 14 Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 14 Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 15
Appendix C. Comparative Evaluation of Different Approaches . . . 15 Appendix C. Comparative Evaluation of Different Approaches . . . 16
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by
network-based management functions that enable IP mobility for a host network-based management functions that enable IP mobility for a host
without requiring its participation in any mobility-related without requiring its participation in any mobility-related
signaling. Additional network entities, i.e., the Local Mobility signaling. Additional network entities called the Local Mobility
Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for
managing IP mobility on behalf of the mobile node (MN). managing IP mobility on behalf of the mobile node (MN).
With these routing entities in place, the mobile node looses With these entities in place, the mobile node looses transparent end-
transparent end-to-end connectivity to the static Internet, and in to-end connectivity to the static Internet, and in the particular
the particular case of multicast communication, group membership case of multicast communication, group membership management as
management as signaled by the Multicast Listener Discovery protocol signaled by the Multicast Listener Discovery protocol [RFC3810],
[RFC3810], [RFC2710] requires a dedicated treatment at the network [RFC2710] requires dedicated treatment at the network side, see
side, see [I-D.deng-multimob-pmip6-requirement]. [I-D.deng-multimob-pmip6-requirement].
Multicast routing functions need a careful placement within the Multicast routing functions need to be placed carefully within the
PMIPv6 domain to augment unicast transmission with group PMIPv6 domain to augment unicast transmission with group
communication services. [RFC5213] does not explicitly address communication services. [RFC5213] does not explicitly address
multicast communication, whereas bi-directional home tunneling, the multicast communication and relies on the minimal multicast support
minimal multicast support arranged by MIPv6, cannot be applied in provided by MIPv6. But unfortunately bi-directional home tunneling,
network-based management scenarios: A mobility-unaware node will the minimal multicast support arranged by MIPv6, cannot be applied in
experience no reason to initiate a tunnel with an entity of mobility network-based management scenarios, since a mobility-unaware node
support. will not initiate such a tunnel after movement.
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.
Mobile Nodes in this scenario remain agnostic of multicast mobility Mobile Nodes in this scenario remain agnostic of multicast mobility
operations. Accrediting the problem space of multicast mobility operations. This document does not address specific optimizations
[RFC5757], this document does not address specific optimizations and and efficiency improvements of multicast routing for network-based
efficiency improvements of multicast routing in network-centered mobility discussed in [RFC5757], as such solutions would require
mobility beyond base potentials, as such solutions would require changes to the base PMIPv6 protocol [RFC5213].
changes to the base specification of [RFC5213].
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] and [RFC5213], as well as the multicast edge protocols [RFC3775] and [RFC5213], as well as the multicast edge
related protocols [RFC3810] and [RFC4605]. related protocols [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
skipping to change at page 5, line 41 skipping to change at page 4, line 41
|MAG1| |MAG2| MLD Proxy |MAG1| |MAG2| MLD Proxy
+----+ +----+ +----+ +----+
| | | | | |
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 following application It will submit MLD Report and Done messages, based on application
desires, thereby 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 LMA-to-MAG tunnel (cf., section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel
interface defines an MLD proxy domain at the MAG, containing all interface defines an MLD proxy domain at the MAG, and it contains all
downstream links to MNs that share this LMA. According to standard downstream links to MNs that share this specific LMA. According to
proxy operations, MLD Report messages will be forwarded under standard proxy operations, MLD Report messages will be forwarded
aggregation up the tunnel interface to its corresponding LMA. under aggregation up the tunnel interface to its 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
implement appropriate multicast forwarding states at its tunnel create appropriate multicast forwarding states at its tunnel
interface. Traffic arriving for groups under subscription will interface. Traffic arriving for subscribed groups will arrive at the
arrive at the LMA, which it will forward according to all its group/ LMA, and the LMA will forward this traffic according to its group/
source states. In addition, the LMA will naturally act as an MLD source states. In addition, the LMA will act as an MLD querier,
querier, seeing its downstream tunnel interfaces as multicast enabled seeing its downstream tunnel interfaces as multicast enabled links.
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 of [RFC5213]). identified by its Binding Update List (cf., section 6 of [RFC5213]).
As specified for MLD proxies, the MAG will forward multicast traffic As specified for MLD proxies, the MAG will forward multicast traffic
and initiate related signaling down the appropriate access links to and initiate related signaling down the appropriate access links to
the MNs. In proceeding this way, all multicast-related signaling and the MNs. Hence all multicast-related signaling and the data traffic
the data traffic will transparently flow from the LMA to the MN on an will transparently flow from the LMA to the MN on an LMA-specific
LMA-specific tree, which is shared among the multicast sources. tree, which is shared among the multicast sources.
In case of a mobility handover, the MN (unaware of IP mobility) will In case of a handover, the MN (unaware of IP mobility) will not send
refrain from submitting unsolicited MLD reports. Instead, the MAG is unsolicited MLD reports. Instead, the MAG is required to maintain
required to maintain group memberships in the following way. On group memberships in the following way. On observing a new MN on a
observing a new MN on a downstream link, the MAG sends a General MLD downstream access link, the MAG sends a General MLD Query. Based on
Query. Based on its outcome and the multicast group states its outcome and the multicast group states previously maintained at
previously maintained at the MAG, a corresponding Report will be sent the MAG, a corresponding Report will be sent to the LMA aggregating
to the LMA aggregating group membership states according to the proxy group membership states according to the proxy function. Additional
function. Additional Reports can be omitted, whenever multicast Reports can be omitted when the previously established multicast
forwarding states previously established at the new MAG already cover forwarding states at the new MAG already cover the subscriptions of
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
the MAG can determine 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, and stop here otherwise.
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.
skipping to change at page 8, line 42 skipping to change at page 7, line 42
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
| |<================================================+ | |<================================================+
| | | | Mcast Data | | | | | Mcast Data |
| | | |<===============+ | | | |<===============+
| Mcast Data | | | | | Mcast Data | | | |
|<---------------+ | Mcast Data | | |<---------------+ | Mcast Data | |
| | |<--------------+ | | | |<--------------+ |
| | | | | | | | | |
Figure 2: Call Flow of Multicast-enabled PMIP Figure 2: Call Flow of Multicast-enabled PMIP 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 its IPv4 stack enabled in a PMIPv6 domain. nodes that operate with their IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide an IPv4 home address mobility support PMIPv6 can provide IPv4 home address mobility support [RFC5844].
[I-D.ietf-netlmm-pmip6-ipv4-support]. Such mobile node will use IGMP Such mobile nodes will use IGMP [RFC2236],[RFC3376] signaling for
[RFC2236],[RFC3376] signaling for multicast, which is handled by an multicast, which is handled by an IGMP proxy function at the MAG in
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 multicast inter-operates with PMIPv6. It is worth noting that multicast
streams can possibly be distributed on redundant paths that lead to streams can possibly be distributed on redundant paths that lead to
duplicate traffic arriving from different LMAs at one MAG, and can duplicate traffic arriving from different LMAs at one MAG, and can
cause multiple data transmissions from an MAG over one wireless cause multiple data transmissions from an MAG over one wireless
domain to different MNs (see Appendix C for further considerations). domain to different MNs (see Appendix C for further considerations).
4. Deployment Details 4. Deployment Details
skipping to change at page 9, line 37 skipping to change at page 8, line 38
upstream tunnel interface that has been established with an LMA. The upstream tunnel interface that has been established with an LMA. The
MAG decides on the mapping of downstream links to a proxy instance 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 (and hence an upstream link to an LMA) based on the regular Binding
Update List as maintained by PMIPv6 standard operations (cf., section Update List as maintained by PMIPv6 standard operations (cf., section
6.1 of [RFC5213]). As links connecting MNs and MAGs change under 6.1 of [RFC5213]). As links connecting MNs and MAGs change under
mobility, MLD proxies at MAGs MUST be able to dynamically add and mobility, MLD proxies at MAGs MUST be able to dynamically add and
remove downstream interfaces in its configuration. remove downstream interfaces in its configuration.
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 a regular MLD proxy operations: it will insert/update/remove multicast
multicast forwarding state on the incoming interface, and state forwarding state on the incoming interface, and will merge state
updates will be merged into the MLD proxy membership database. An updates into the MLD proxy membership database. It will then send an
aggregated Report will be sent to the upstream tunnel of the MAG when aggregated Report to the upstream tunnel to the LMA when the
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/source-specific
forwarding states as acquired for each downstream interface within forwarding states as acquired for each downstream interface within
the MLD proxy instance. At this stage, it is important to stress the MLD proxy instance. At this stage, it is important to note that
that IGMP/MLD proxy implementations capable of multiple instances are IGMP/MLD proxy implementations capable of multiple instances are
expected to closely follow the specifications of section 4.2 in expected to closely follow the specifications of section 4.2 in
[RFC4605], i.e., treat proxy instances in isolation of each other [RFC4605], i.e., treat proxy instances in isolation of each other
while forwarding. while forwarding.
In case of a mobility handover, the MAG will continue to manage After a handover, the MAG will continue to manage upstream tunnels
upstream tunnels and downstream interfaces as foreseen in the PMIPv6 and downstream interfaces as specified in the PMIPv6 specification.
specification. It MUST dynamically associate new access links to It MUST dynamically associate new access links to proxy instances
proxy instances that for a MN provide up-link to its corresponding that include the upstream connection to the corresponding LMA. The
LMA. In addition, it MUST assure consistency of its up- and MAG detects the arrival of a new MN by receiving a router
downstream interfaces that change under mobility with MLD proxy solicitation message and by an upcoming link. To learn about
instances and its multicast forwarding states. The MAG will detect multicast groups subscribed by a newly attaching MN, the MAG SHOULD
the arrival of a new MN by receiving a router solicitation message send a General Query to the MN's link. Querying an upcoming
and by an upcoming link. To learn about multicast groups subscribed interface is a standard operation of MLD queriers (see Appendix A)
by a newly attaching MN, the MAG sends a General Query to the MN's and is performed immediately after address configuration. In
link. Querying an upcoming interface is a standard operation of MLD addition, an MLD query SHOULD be initiated by the proxy instance, as
queriers (see Appendix A) and performed immediately after address soon as a new interface has been configured for downstream. In case,
configuration. In addition, an MLD query SHOULD be initiated by the the access link between MN and MAG goes down, interface-specific
proxy instance, as soon as a new interface has been configured for multicast states change. Both cases may alter the composition of the
downstream. In case, the access link between MN and MAG goes down, membership database and this will trigger corresponding Reports
interface-specific multicast states change. Both cases may alter the towards the LMA. Note that the actual observable state depends on
composition of the membership database, which then will trigger the access link model in use.
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 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 proxy downstream interface. Such occurrences
are equivalent to a General Query loss. To prevent erroneous query are equivalent to a General Query loss. To prevent erroneous query
timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to
the mobility regime. In particular, MLD timers and the Robustness the mobility regime. In particular, MLD timers and the Robustness
Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant
with the time scale of handover operations and proxy configurations with the time scale of handover operations and proxy configurations
in the PMIPv6 domain. in the PMIPv6 domain.
In proceeding this way, the MAG is entitled 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 per arriving from different LMA upstream interfaces.Furthermore, a
group forwarding into the wireless domain is restricted to the link multipoint channel forwarding into the wireless domain is prevented
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), it establishes/maintains/
removes group/source-specific multicast forwarding states at its removes group/source-specific multicast forwarding states at its
corresponding downstream tunnel interfaces. At the same time, it corresponding downstream tunnel interfaces. At the same time, it
procures for aggregated multicast membership maintenance at its 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 experiences its tunnel interfaces as multicast the MAGs, the LMA treats its tunnel interfaces as multicast enabled
enabled downstream links, serving zero to many listening nodes. downstream links, serving zero to many listening nodes. Multicast
Multicast traffic arriving at the LMA is transparently forwarded traffic arriving at the LMA is transparently forwarded according to
according to its multicast forwarding information base. its multicast forwarding information base.
On the occurrence of a mobility handover, the LMA will receive After a handover, the LMA will receive Binding De-Registrations and
Binding Lifetime De-Registrations and Binding Lifetime Extensions Binding Lifetime Extensions that will cause a re-mapping of home
that will cause a re-mapping of home network prefixes to Proxy-CoAs network prefix(es) to a new Proxy-CoA in its Binding Cache (see
in its Binding Cache (see section 5.3 of [RFC5213]). The multicast section 5.3 of [RFC5213]). The multicast forwarding states require
forwarding states require updating, as well, if the MN within an MLD updating, as well, if the MN within an MLD proxy domain is the only
proxy domain is the only receiver of a multicast group. Two cases receiver of a multicast group. Two different cases need to be
need distinction: 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
skipping to change at page 11, line 41 skipping to change at page 10, line 40
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 [I-D.ietf-netlmm-pmip6-ipv4-support]. communication as specified in [RFC5844]. For this purpose, LMAs can
For this purpose, LMAs can register IPv4-Proxy-CoAs in its Binding register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide
Caches and MAGs can provide IPv4 support in access networks. IPv4 support in access networks. Correspondingly, multicast
Correspondingly, multicast membership management will be performed by membership management will be performed by the MN using IGMP. For
the MN using IGMP. For multicast support on the network side, an multicast support on the network side, an IGMP proxy function needs
IGMP proxy function needs to be deployed at MAGs in exactly the same to be deployed at MAGs in exactly the same way as for IPv6.
way as for IPv6. [RFC4605] defines IGMP proxy behaviour in full [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/
agreement with IPv6/MLD. Thus IPv4 support can be transparently MLD. Thus IPv4 support can be transparently provided following the
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.
4.5. Multicast Availability throughout the Access Network 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 scenario, it
can autonomously assign multicast channel subscriptions to individual
interfaces. While doing so, 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 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 AMT
[I-D.ietf-mboned-auto-multicast]. [I-D.ietf-mboned-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 into 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.
These solutions have in common 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 sketched in [RFC3775]. Care must be
taken to avoid service disruptions due to tardy multicast routing taken to avoid service disruptions due to tardy multicast routing
operations [RFC5757], and the different possible approaches should be operations, and to adapt to different link-layer technologies
carefully investigated. Such work is beyond the scope of this [RFC5757]. The different possible approaches should be carefully
document. investigated. Such work is beyond the scope of this document.
4.6. A Note on Explicit Tracking 4.7. A Note on Explicit Tracking
IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with
explicit tracking, which allows routers to monitor each multicast explicit tracking, which allows routers to monitor each multicast
receiver. This mechanism is not standardized yet, but widely receiver. This mechanism is not standardized yet, but widely
implemented by vendors as it supports faster leave latencies and implemented by vendors as it supports faster leave latencies and
reduced signaling. 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.
skipping to change at page 13, line 36 skipping to change at page 13, line 7
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
This draft does neither introduce additional messages nor novel This draft does not introduce additional messages or novel protocol
protocol operations. Consequently, no new threats arrive from operations. Consequently, no new threats are introduced by this
procedures described in this document in excess to [RFC3810], document in addition to those identified as security concerns of
[RFC4605] and [RFC5213] security concerns. [RFC3810], [RFC4605], [RFC5213], and [RFC5844].
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 for 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.
8. Acknowledgements 8. Acknowledgements
This memo is the outcome of extensive previous discussions and a This memo is the outcome of extensive previous discussions and a
follow-up of several initial drafts on the subject. The authors follow-up of several initial drafts on the subject. The authors
would like to thank (in alphabetical order) Luis Contreras, Gorry would like to thank (in alphabetical order) Luis Contreras, Greg
Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Sebastian Daley, Gorry Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen,
Meiling, Liu Hui, Imed Romdhani, Behcet Sarikaya, Stig Venaas, and Guang Lu, Sebastian Meiling, Liu Hui, Imed Romdhani, Behcet Sarikaya,
Juan Carlos Zuniga for advice, help and reviews of the document. Stig Venaas, and Juan Carlos Zuniga for advice, help and reviews of
Funding by the German Federal Ministry of Education and Research the document. Funding by the German Federal Ministry of Education
within the G-LAB Initiative is gratefully acknowledged. and Research within the G-LAB Initiative is gratefully acknowledged.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-18
(work in progress), February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 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
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
skipping to change at page 14, line 43 skipping to change at page 14, line 20
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"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
Mobile IPv6", RFC 5844, May 2010.
9.2. Informative References 9.2. Informative References
[I-D.deng-multimob-pmip6-requirement] [I-D.deng-multimob-pmip6-requirement]
Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang,
"Multicast Support Requirements for Proxy Mobile IPv6", "Multicast Support Requirements for Proxy Mobile IPv6",
draft-deng-multimob-pmip6-requirement-02 (work in draft-deng-multimob-pmip6-requirement-02 (work in
progress), July 2009. progress), July 2009.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-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-09 (work in (AMT)", draft-ietf-mboned-auto-multicast-10 (work in
progress), June 2008. progress), March 2010.
[I-D.zuniga-multimob-smspmip] [I-D.zuniga-multimob-smspmip]
Zuniga, J., Lu, G., and A. Rahman, "Support Multicast Zuniga, J., Lu, G., and A. Rahman, "Support Multicast
Services Using Proxy Mobile IPv6", Services Using Proxy Mobile IPv6",
draft-zuniga-multimob-smspmip-02 (work in progress), draft-zuniga-multimob-smspmip-02 (work in progress),
February 2010. February 2010.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
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.
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
skipping to change at page 17, line 19 skipping to change at page 16, line 47
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 groups.
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 approx. 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. described above. In addition, we display the number of packet
streams that cross the interconnecting (wired) network within a
PMIPv6 domain.
Setting 1: Setting 1:
+===================+================+===================+ +===================+==============+================+===============+
| PMIP multicast | # of redundant | # of sim. streams | | PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams at MAG | at LMA / LMA-M | | scheme | streams | streams | streams in |
+===================+================+===================+ | | at MAG | at LMA/LMA-M | the network |
| Combined Unicast/ | 0 | 250,000 | +===================+==============+================+===============+
| Multicast LMA | | | | Combined Unicast/ | 0 | 250,000 | 1,000,000 |
+-------------------+----------------+-------------------+ | Multicast LMA | | | |
| Dedicated | 0 | 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 1,000,000 MNs are subscribed to distinct multicast groups
Setting 2: Setting 2:
+===================+================+===================+ +===================+==============+================+===============+
| PMIP multicast | # of redundant | # of sim. streams | | PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams at MAG | at LMA / LMA-M | | scheme | streams | streams | streams in |
+===================+================+===================+ | | at MAG | at LMA/LMA-M | the network |
| Combined Unicast/ | 4 | 50 | +===================+==============+================+===============+
| Multicast LMA | | | | Combined Unicast/ | 3 | 200 | 800 |
+-------------------+----------------+-------------------+ | Multicast LMA | | | |
| Dedicated | 0 | 200 | +-------------------+--------------+----------------+---------------+
| Multicast LMA | | | | Dedicated | 0 | 200 | 200 |
+-------------------+----------------+-------------------+ | 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 tunnel These considerations of extremal settings show that tunnel
convergence, i.e., duplicate data arriving at a MAG, does cause much convergence, i.e., duplicate data arriving at a MAG, does cause much
smaller problems in scalability than the stream replication at LMAs. smaller problems in scalability than the stream replication at LMAs.
For scenario A it should be also noted that the high stream For scenario A it should be also noted that the high stream
replication requirements at LMAs in setting 1 can be attenuated by replication requirements at LMAs in setting 1 can be attenuated by
deploying additional LMAs in a PMIP domain, while scenario B does not deploying additional LMAs in a PMIP domain, while scenario B does not
allow for distributing the LMA-M, as no handover management is allow for distributing the LMA-M, as no handover management is
available at LMA-M. available at LMA-M.
Appendix D. Change Log Appendix D. Change Log
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 The following changes have been made from the previous individual
version draft-schmidt-multimob-pmipv6-mcast-deployment-04. version draft-schmidt-multimob-pmipv6-mcast-deployment-04.
1. Updated references. 1. Updated references.
2. Corrected typos. 2. Corrected typos.
3. Adjusted title & document name. 3. Adjusted title & document name.
The following changes have been made from The following changes have been made from
 End of changes. 46 change blocks. 
173 lines changed or deleted 209 lines changed or added

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