draft-ietf-multimob-pmipv6-base-solution-01.txt   draft-ietf-multimob-pmipv6-base-solution-02.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: November 26, 2010 link-lab & FU Berlin Expires: December 2, 2010 link-lab & FU Berlin
S. Krishnan S. Krishnan
Ericsson Ericsson
May 25, 2010 May 31, 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-01 draft-ietf-multimob-pmipv6-base-solution-02
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, Local Mobility Anchors of Proxy Mobile IPv6 serve as
subscription anchor points, while Mobile Access Gateways provide MLD multicast subscription anchor points, while Mobile Access Gateways
proxy functions. In this scenario, Mobile Nodes remain agnostic of provide MLD proxy functions. In this scenario, Mobile Nodes remain
multicast mobility operations. agnostic of multicast mobility operations.
Requirements Language Requirements Language
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on November 26, 2010. This Internet-Draft will expire on December 2, 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . 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 . . . 11 4.6. Multicast Availability throughout the Access Network . . . 11
4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12 4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15 Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 15 Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 15
Appendix C. Comparative Evaluation of Different Approaches . . . 16 Appendix C. Comparative Evaluation of Different Approaches . . . 16
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 called 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).
skipping to change at page 3, line 24 skipping to change at page 3, line 24
With these entities in place, the mobile node looses transparent end- With these entities in place, the mobile node looses transparent end-
to-end connectivity to the static Internet, and in the particular to-end connectivity to the static Internet, and in the particular
case of multicast communication, group membership management as case of multicast communication, group membership management as
signaled by the Multicast Listener Discovery protocol [RFC3810], signaled by the Multicast Listener Discovery protocol [RFC3810],
[RFC2710] requires dedicated treatment at the network side, see [RFC2710] requires dedicated treatment at the network side, see
[I-D.deng-multimob-pmip6-requirement]. [I-D.deng-multimob-pmip6-requirement].
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 to augment unicast transmission with group
communication services. [RFC5213] does not explicitly address communication services. [RFC5213] does not explicitly address
multicast communication and relies on the minimal multicast support multicast communication and thus relies on the minimal multicast
provided by MIPv6. But unfortunately bi-directional home tunneling, support provided by MIPv6. But unfortunately, bi-directional home
the minimal multicast support arranged by MIPv6, cannot be applied in tunneling, the minimal multicast support arranged by MIPv6, cannot be
network-based management scenarios, since a mobility-unaware node applied in network-based management scenarios, since a mobility-
will not initiate such a tunnel after movement. unaware node will not initiate such a tunnel after movement.
Consequently, even a minimal multicast listener support in PMIPv6
domains requires an explicit deployment of additional functions, as
is the subject of this document.
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. 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]. changes to the base PMIPv6 protocol [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], [RFC5213] and [RFC5844], as well as the
related protocols [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.
+-------------+ +-------------+
| Content | | Content |
| Source | | Source |
+-------------+ +-------------+
| |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Fixed Internet * * Fixed Internet *
* * * *
skipping to change at page 8, line 4 skipping to change at page 8, line 4
Report" abbreviated by "Join" 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 multicast inter-operates with PMIPv6. It is worth noting that MNs - while
streams can possibly be distributed on redundant paths that lead to being attached to the same MAG, but associated with different LMAs -
duplicate traffic arriving from different LMAs at one MAG, and can can subscribe to the same multicast group. Thereby data could be
cause multiple data transmissions from an MAG over one wireless distributed redundantly in the network and duplicate traffic could
domain to different MNs (see Appendix C for further considerations). arrive at a MAG. Additionally in a point-to-point wireless link
model, an MAG might be forced to transmit the same data over one
wireless domain to different MNs. However, multicast traffic to one
MN will always remain unique, i.e., the mobile multicast distribution
system will never cause duplicate packets arriving at an MN (see
Appendix C for further considerations).
4. Deployment Details 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 its interaction multicast functions at PMIPv6 routers and to define its 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, maintain
and leave groups as if located in the fixed Internet. No specific and leave groups as if located in the fixed Internet. No specific
mobility actions nor implementations are required at the MN. 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 Mobility 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 which it serves, and the
corresponding LMAs associated to each MN. It therefore needs to corresponding LMAs associated to each MN. It therefore needs to
implement an instance of the MLD proxy function [RFC4605] for each implement an instance of the MLD proxy function [RFC4605] for each
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.
skipping to change at page 11, line 34 skipping to change at page 11, line 42
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 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.
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 sketched in [RFC3775]. Care must be
taken to avoid service disruptions due to tardy multicast routing taken to avoid avalanche problems or service disruptions due to tardy
operations, and to adapt to different link-layer technologies multicast routing operations, and to adapt to different link-layer
[RFC5757]. The different possible approaches should be carefully technologies [RFC5757]. The different possible approaches should be
investigated. Such work is beyond the scope of this document. carefully investigated beyond the initial sketch in Appendix C. Such
work is beyond the scope of this document.
4.7. A Note on Explicit Tracking 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
skipping to change at page 17, line 37 skipping to change at page 18, line 22
| 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 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 (avalanche problem). For scenario A it should be also noted that the
replication requirements at LMAs in setting 1 can be attenuated by high stream replication requirements at LMAs in setting 1 can be
deploying additional LMAs in a PMIP domain, while scenario B does not attenuated by deploying additional LMAs in a PMIP domain, while
allow for distributing the LMA-M, as no handover management is scenario B does not allow for distributing the LMA-M, as no handover
available at LMA-M. management is available at LMA-M.
Appendix D. Change Log Appendix D. Change Log
The following changes have been made from version 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. draft-ietf-multimob-pmipv6-base-solution-00.
1. Added section on multihoming. 1. Added section on multihoming.
2. Updated security section. 2. Updated security section.
3. Several editorial improvements and minor extensions. 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.
 End of changes. 19 change blocks. 
40 lines changed or deleted 53 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/