draft-ietf-multimob-pmipv6-source-03.txt   draft-ietf-multimob-pmipv6-source-04.txt 
MULTIMOB Group T C. Schmidt, Ed. MULTIMOB Group T. Schmidt, Ed.
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: Standards Track S. Gao Intended status: Standards Track S. Gao
Expires: August 29, 2013 H. Zhang Expires: January 14, 2014 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
February 25, 2013 July 13, 2013
Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
draft-ietf-multimob-pmipv6-source-03 draft-ietf-multimob-pmipv6-source-04
Abstract Abstract
Multicast communication can be enabled in Proxy Mobile IPv6 domains Multicast communication can be enabled in Proxy Mobile IPv6 domains
via the Local Mobility Anchors by deploying MLD Proxy functions at via the Local Mobility Anchors by deploying MLD Proxy functions at
Mobile Access Gateways, via a direct traffic distribution within an Mobile Access Gateways, via a direct traffic distribution within an
ISP's access network, or by selective route optimization schemes. ISP's access network, or by selective route optimization schemes.
This document describes the support of mobile multicast senders in This document describes the support of mobile multicast senders in
Proxy Mobile IPv6 domains for all three scenarios. Protocol Proxy Mobile IPv6 domains for all three scenarios. Protocol
optimizations for synchronizing PMIPv6 with PIM, as well as extended optimizations for synchronizing PMIPv6 with PIM, as well as a peering
MLD Proxy functions are presented. Mobile sources always remain function for MLD Proxies defined. Mobile sources always remain
agnostic of 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
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). 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 August 29, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 5 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Base Solution for Source Mobility: Details . . . . . . . . 9 3.2. Base Solution for Source Mobility: Details . . . . . . . 7
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 7
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 7
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 7
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 8
3.2.5. Efficiency of the Distribution System . . . . . . . . 11 3.2.5. Efficiency of the Distribution System . . . . . . . . 9
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 11 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 11
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 12
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 14 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 12
4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 12
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 14 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 12
4.3.2. Operations of PIM in Phase One . . . . . . . . . . . . 15 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 13
4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . . 16 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 14
4.3.4. Operations of PIM in Phase Three . . . . . . . . . . . 16 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 14
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . . 17 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 15
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 17 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 15
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 18 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 16
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 18 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 16
5. Extended MLD Proxy Function for Optimized Source Mobility 5. Extended MLD Proxy Function for Optimized Source Mobility in
in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Peering Function for MLD Proxies . . . . . . . . . . . . . 19 5.1. Peering Function for MLD Proxies . . . . . . . . . . . . 17
5.1.1. Operations at the Multicast Sender . . . . . . . . . . 19 5.1.1. Operations at the Multicast Sender . . . . . . . . . 18
5.1.2. Operations at the Multicast Listener . . . . . . . . . 20 5.1.2. Operations at the Multicast Listener . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . . 23 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 21
A.1. Operations for Local Multicast Sources . . . . . . . . . . 24 A.1. Operations for Local Multicast Sources . . . . . . . . . 22
A.2. Operations for Local Multicast Subscribers . . . . . . . . 24 A.2. Operations for Local Multicast Subscribers . . . . . . . 22
Appendix B. Evaluation of Traffic Flows . . . . . . . . . . . . . 24 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
[RFC6275] by network-based management functions that enable IP [RFC6275] 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). An MN connected to a PMIPv6 domain, which only operates (MN). An MN connected to a PMIPv6 domain, which only operates
skipping to change at page 6, line 5 skipping to change at page 4, line 28
3. Base Solution for Source Mobility and PMIPv6 Routing 3. Base Solution for Source Mobility and PMIPv6 Routing
3.1. Overview 3.1. 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. MAGs play the role of first-hop domains is illustrated in Figure 1. MAGs play the role of first-hop
access routers that serve multiple MNs on the downstream while access routers that serve multiple MNs on the downstream while
running an MLD/IGMP proxy instance for every LMA upstream tunnel. running an MLD/IGMP proxy instance for every LMA upstream tunnel.
+-------------+ +-------------+
| Multicast | | Multicast |
| Listeners | | Listeners |
+-------------+ +-------------+
| |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Fixed Internet * * Fixed Internet *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
/ \ / \
+----+ +----+ +----+ +----+
|LMA1| |LMA2| Multicast Anchor |LMA1| |LMA2| Multicast Anchor
+----+ +----+ +----+ +----+
LMAA1 | | LMAA2 LMAA1 | | LMAA2
| | | |
\\ //\\ \\ //\\
\\ // \\ \\ // \\
\\ // \\ Unicast Tunnel \\ // \\ Unicast Tunnel
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
Proxy-CoA1 || || Proxy-CoA2 Proxy-CoA1 || || Proxy-CoA2
+----+ +----+ +----+ +----+
|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
Multicast Sender + Listener(s) Multicast Sender + Listener(s)
Figure 1: Reference Network for Multicast Deployment in PMIPv6 with Figure 1: Reference Network for Multicast Deployment in PMIPv6 with
Source Mobility Source Mobility
An MN in a PMIPv6 domain will decide on multicast data transmission An MN in a PMIPv6 domain will decide on multicast data transmission
completely independent of its current mobility conditions. It will completely independent of its current mobility conditions. It will
send packets as initiated by applications, using its source address send packets as initiated by applications, using its source address
with Home Network Prefix (HNP) and a multicast destination address with Home Network Prefix (HNP) and a multicast destination address
chosen by application needs. Multicast packets will arrive at the chosen by application needs. Multicast packets will arrive at the
currently active MAG via one of its downstream local (wireless) currently active MAG via one of its downstream local (wireless)
links. A multicast unaware MAG would simply discard these packets in links. A multicast unaware MAG would simply discard these packets in
the absence of a multicast routing information base (MRIB). the absence of a multicast routing information base (MRIB).
skipping to change at page 7, line 28 skipping to change at page 5, line 51
forwards data to the fixed Internet, whenever forwarding states are forwards data to the fixed Internet, whenever forwarding states are
maintained by multicast routing. If the LMA is acting as another MLD maintained by multicast routing. If the LMA is acting as another MLD
proxy, it will forward the multicast data to its upstream interface, proxy, it will forward the multicast data to its upstream interface,
and to downstream interfaces with matching subscriptions, and to downstream interfaces with matching subscriptions,
accordingly. accordingly.
In case of a handover, the MN (unaware of IP mobility) can continue In case of a handover, the MN (unaware of IP mobility) can continue
to send multicast packets as soon as network connectivity is to send multicast packets as soon as network connectivity is
reconfigured. At this time, the MAG has determined the corresponding reconfigured. At this time, the MAG has determined the corresponding
LMA, and IPv6 unicast address configuration (including PMIPv6 LMA, and IPv6 unicast address configuration (including PMIPv6
bindings) has been performed. Still multicast packets arriving at bindings) has been completed. Still multicast packets arriving at
the MAG are discarded (if not buffered) until the MAG has completed the MAG are discarded (if not buffered) until the MAG has completed
the following steps. the following steps.
1. The MAG has determined that the MN is admissible to multicast 1. The MAG has determined that the MN is admissible to multicast
services. services.
2. The MAG has added the new downstream link to the MLD proxy 2. The MAG has added the new downstream link to the MLD proxy
instance with up-link to the corresponding LMA. instance with up-link to the corresponding LMA.
As soon as the MN's uplink is associated with the corresponding MLD As soon as the MN's uplink is associated with the corresponding MLD
skipping to change at page 8, line 49 skipping to change at page 7, line 16
PMIPv6 can provide IPv4 home address mobility support [RFC5844]. PMIPv6 can provide IPv4 home address mobility support [RFC5844].
IPv4 multicast is handled by an IGMP proxy function at the MAG in an IPv4 multicast is handled by an IGMP proxy function at the MAG in an
analogous way. analogous way.
Following these deployment steps, multicast traffic distribution Following these deployment steps, multicast traffic distribution
transparently inter-operates with PMIPv6. It is worth noting that an transparently inter-operates with PMIPv6. It is worth noting that an
MN - while being attached to the same MAG as the mobile source, but MN - while being attached to the same MAG as the mobile source, but
associated with a different LMA - cannot receive multicast traffic on associated with a different LMA - cannot receive multicast traffic on
a shortest path. Instead, multicast streams flow up to the LMA of a shortest path. Instead, multicast streams flow up to the LMA of
the mobile source, are transferred to the LMA of the mobile listener the mobile source, are transferred to the LMA of the mobile listener
and tunneled downwards to the MAG again (see Appendix B for further and tunneled downwards to the MAG again (see Section 5 for further
considerations). optimizations).
3.2. Base Solution for Source Mobility: Details 3.2. Base Solution for Source Mobility: Details
Incorporating multicast source mobility in PMIPv6 requires to deploy A support of multicast source mobility in PMIPv6 requires to deploy
general multicast functions at PMIPv6 routers and to define their general multicast functions at PMIPv6 routers and to define their
interaction with the PMIPv6 protocol in the following way. interaction with the PMIPv6 protocol in the following way.
3.2.1. Operations of the Mobile Node 3.2.1. Operations of the Mobile Node
A Mobile Node willing to send multicast data will proceed as if A Mobile Node willing to send multicast data will proceed as if
attached to the fixed Internet. No specific mobility or other attached to the fixed Internet. No specific mobility or other
multicast related functionalities are required at the MN. multicast related functionalities are required at the MN.
3.2.2. Operations of the Mobile Access Gateway 3.2.2. Operations of the Mobile Access Gateway
skipping to change at page 10, line 6 skipping to change at page 8, line 20
3.2.3.1. Local Mobility Anchors Operating PIM 3.2.3.1. Local Mobility Anchors Operating PIM
Local Mobility Anchors that operate the PIM-SM routing protocol Local Mobility Anchors that operate the PIM-SM routing protocol
[RFC4601] will require sources to be directly connected for sending [RFC4601] will require sources to be directly connected for sending
PIM registers to the RP. This does not hold in a PMIPv6 domain, as PIM registers to the RP. This does not hold in a PMIPv6 domain, as
MAGs are routers intermediate to MN and the LMA. In this sense, MNs MAGs are routers intermediate to MN and the LMA. In this sense, MNs
are multicast sources external to the PIM-SM domain. are multicast sources external to the PIM-SM domain.
To mitigate this incompatibility common to all subsidiary MLD proxy To mitigate this incompatibility common to all subsidiary MLD proxy
domains, the LMA should act as a PIM Border Router and activate the domains, the LMA MUST act as a PIM Border Router and activate the
Border-bit. In this case, the DirectlyConnected(S) is treated as Border-bit. In this case, the DirectlyConnected(S) is treated as
being TRUE for mobile sources and the PIM-SM forwarding rule "iif == being TRUE for mobile sources and the PIM-SM forwarding rule "iif ==
RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel
interface from MAG to LMA is considered as not part of the PIM-SM interface from MAG to LMA is considered as not part of the PIM-SM
component of the LMA (see A.1 of [RFC4601] ). component of the LMA (see A.1 of [RFC4601] ).
In addition, an LMA serving as PIM Designated Router is connected to In addition, an LMA serving as PIM Designated Router is connected to
MLD proxies via individual IP-tunnel interfaces and will experience MLD proxies via individual IP-tunnel interfaces and will experience
changing PIM source states on handover. As the incoming interface changing PIM source states on handover. As the incoming interface
connects to a point-to-point link, PIM Assert contention is not connects to a point-to-point link, PIM Assert contention is not
active, and incoming interface validation is only performed by RPF active, and incoming interface validation is only performed by RPF
checks. Consequently, a PIM DR should update incoming source states, checks. Consequently, a PIM DR SHOULD update incoming source states,
as soon as RPF inspection succeeds, i.e., after PMIPv6 forwarding as soon as RPF inspection succeeds, i.e., after PMIPv6 forwarding
state update. Consequently, PIM routers SHOULD be able to manage state update. Consequently, PIM routers SHOULD be able to manage
these state changes, but some implementations are expected to these state changes, but some implementations are expected to
incorrectly refuse packets until the previous state has timed out. incorrectly refuse packets until the previous state has timed out.
Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
respect to source location and does not require special respect to source location and does not require special
configurations or state management for sources. configurations or state management for sources.
3.2.4. IPv4 Support 3.2.4. IPv4 Support
skipping to change at page 11, line 14 skipping to change at page 9, line 29
the MAG-LMA tunnel can be individually identified per MN by the GRE the MAG-LMA tunnel can be individually identified per MN by the GRE
keys. This scenario still does not impose any special treatment of keys. This scenario still does not impose any special treatment of
multicast communication for the following reasons. multicast communication for the following reasons.
Multicast streams from and to MNs arrive at a MAG on point-to-point Multicast streams from and to MNs arrive at a MAG on point-to-point
links (identical to unicast). Multicast data transmission from the links (identical to unicast). Multicast data transmission from the
MAG to the corresponding LMA is link-local between the routers and MAG to the corresponding LMA is link-local between the routers and
routing/forwarding remains independent of any individual MN. So the routing/forwarding remains independent of any individual MN. So the
MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain
GRE encapsulation in multicast communication (including MLD queries GRE encapsulation in multicast communication (including MLD queries
and reports). Multicast traffic sent upstream and downstream of MAG- and reports). Multicast traffic is transmitted as router-to-router
to-LMA tunnels proceeds as router-to-router forwarding according to forwarding via the MAG-to-LMA tunnels and according to the multicast
the multicast routing information base (MRIB) of the MAG or LMA and routing information base (MRIB) of the MAG or the LMA. It remains
independent of MN's unicast addresses, while the MAG proxy instance independent of MN's unicast addresses, while the MAG proxy instance
re-distributes multicast data down the point-to-point links re-distributes multicast data down the point-to-point links
(interfaces) according to its own MRIB, independent of MN's IP (interfaces) according to its local subscription states, independent
addresses. of IP addresses of the MN.
3.2.5. Efficiency of the Distribution System 3.2.5. Efficiency of the Distribution System
The distribution system of the base solution directly follows PMIPv6 The distribution system of the base solution directly follows PMIPv6
routing rules, and organizes multicast domains with respect to LMAs. routing rules, and organizes multicast domains with respect to LMAs.
Thus, no coordination between address spaces or services is required Thus, no coordination between address spaces or services is required
between the different instances, provided their associated LMAs between the different instances, provided their associated LMAs
belong to disjoint multicast domains. Routing is optimal for belong to disjoint multicast domains. Routing is optimal for
communication between MNs of the same domain, or stationary communication between MNs of the same domain, or stationary
subscribers. subscribers.
In the following efficiency-related issues remain. In the following, efficiency-related issues remain.
Multicast reception at LMA In the current deployment scenario, the Multicast reception at LMA In the current deployment scenario, the
LMA will receive all multicast traffic originating from its LMA will receive all multicast traffic originating from its
associated MNs. There is no mechanism to suppress upstream associated MNs. There is no mechanism to suppress upstream
forwarding in the absence of receivers. forwarding in the absence of receivers.
MNs on the same MAG using different LMAs For a mobile receiver and a MNs on the same MAG using different LMAs For a mobile receiver and a
source that use different LMAs, the traffic has to go up to one source that use different LMAs, the traffic has to go up to one
LMA, cross over to the other LMA, and then be tunneled back to the LMA, cross over to the other LMA, and then be tunneled back to the
same MAG, causing redundant flows in the access network and at the same MAG, causing redundant flows in the access network and at the
skipping to change at page 12, line 9 skipping to change at page 10, line 27
There are deployment scenarios, where multicast services are There are deployment scenarios, where multicast services are
available throughout the access network independent of the PMIPv6 available throughout the access network independent of the PMIPv6
routing system [I-D.ietf-multimob-pmipv6-ropt]. In these cases, the routing system [I-D.ietf-multimob-pmipv6-ropt]. In these cases, the
visited networks grant a local content distribution service (in visited networks grant a local content distribution service (in
contrast to LMA-based home subscription) with locally optimized contrast to LMA-based home subscription) with locally optimized
traffic flows. It is also possible to deploy a mixed service model traffic flows. It is also possible to deploy a mixed service model
of local and LMA-based subscriptions, provided a unique way of of local and LMA-based subscriptions, provided a unique way of
service selection is implemented. For example, access routers (MAGs) service selection is implemented. For example, access routers (MAGs)
could decide on service access based on the multicast address G or could decide on service access based on the multicast address G or
the SSM channel (S,G) under request (see Section 5 for a further the SSM channel (S,G) under request (see Appendix A for further
discussion). discussions).
4.1. Overview 4.1. Overview
Direct multicast access can be supported by Direct multicast access can be supported by
o native multicast routing provided by one multicast router that is o native multicast routing provided by one multicast router that is
neighboring MLD proxies deployed at MAGs within a flat access neighboring MLD proxies deployed at MAGs within a flat access
network, or via tunnel uplinks, network, or via tunnel uplinks,
o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM
[RFC5015] deployed at the MAGs. [RFC5015] deployed at the MAGs.
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Multicast * * Multicast *
+----+ * Infrastructure * +----+ +----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA | |LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+ +----+ *** *** *** *** +----+
| // \\ | | // \\ |
\\ // \\ PMIP (unicast) | \\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** // PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** // (unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *// \\ // \\ // \\* Multicast *//
|| || || || * || Routing || * || || || || * || Routing || *
+----+ +----+ * +----+ +----+ * +----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| * MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+* +----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***| | | | | |*** *** ***|
| | | | | | | | | | | |
MN1 MN2 MN3 MN1 MN2 MN3 MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast
Access and (b) Dynamic Multicast Routing at MAGs Access and (b) Dynamic Multicast Routing at MAGs
Figure 3 displays the corresponding deployment scenarios, which Figure 3 displays the corresponding deployment scenarios, which
separate multicast from PMIPv6 unicast routing. It is assumed separate multicast from PMIPv6 unicast routing. It is assumed
throughout these scenarios that all MAGs (MLD proxies) are linked to throughout these scenarios that all MAGs (MLD proxies) are linked to
a single multicast routing domain. Noteworthy, this scenario a single multicast routing domain. Notably, this scenario requires
requires coordination of multicast address utilization and service coordination of multicast address utilization and service bindings.
bindings.
Multicast traffic distribution can be simplified in these scenarios. Multicast traffic distribution can be simplified in these scenarios.
A single proxy instance at MAGs with up-link into the multicast A single proxy instance at MAGs with up-link into the multicast
domain will serve as a first hop multicast gateway and avoid traffic domain will serve as a first hop multicast gateway and avoid traffic
duplication or detour routing. Multicast routing functions at MAGs duplication or detour routing. Multicast routing functions at MAGs
will seamlessly embed access gateways within a multicast cloud. will seamlessly embed access gateways within a multicast cloud.
However, mobility of the multicast source in this scenario will However, mobility of the multicast source in this scenario will
require some multicast routing protocols to rebuild distribution require some multicast routing protocols to rebuild distribution
trees. This can cause significant service disruptions or delays (see trees. This can cause significant service disruptions or delays (see
[RFC5757] for further aspects). Deployment details are specific to [RFC5757] for further aspects). Deployment details are specific to
skipping to change at page 13, line 38 skipping to change at page 12, line 5
upstream tunnels that terminate at a common multicast router. upstream tunnels that terminate at a common multicast router.
Multicast data submitted by a mobile source will reach the MLD proxy Multicast data submitted by a mobile source will reach the MLD proxy
at the MAG that subsequently forwards flows to the upstream, and all at the MAG that subsequently forwards flows to the upstream, and all
downstream interfaces with appropriate subscriptions. Traversing the downstream interfaces with appropriate subscriptions. Traversing the
upstream will lead traffic into the multicast infrastructure (e.g., upstream will lead traffic into the multicast infrastructure (e.g.,
to a PIM Designated Router) which will route packets to all local to a PIM Designated Router) which will route packets to all local
MAGs that have joined the group, as well as further upstream MAGs that have joined the group, as well as further upstream
according to protocol procedures and forwarding states. according to protocol procedures and forwarding states.
On handover, a mobile source will reattach at a new MAG and can On handover, a mobile source will reattach to a new MAG and can
continue to send multicast packets as soon as PMIPv6 unicast continue to send multicast packets as soon as PMIPv6 unicast
configurations have completed. Like at the previous MAG, the new MLD configurations have completed. Like at the previous MAG, the new MLD
proxy will forward data upstream and downstream to subscribers. proxy will forward data upstream and downstream to subscribers.
Listeners local to the previous MAG will continue to receive group Listeners local to the previous MAG will continue to receive group
traffic via the local multicast distribution infrastructure following traffic via the local multicast distribution infrastructure following
aggregated listener reports of the previous proxy. In general, aggregated listener reports of the previous proxy. In general,
traffic from the mobile source continues to be transmitted via the traffic from the mobile source continues to be transmitted via the
same next-hop router using the same source address and thus remains same next-hop router using the same source address and thus remains
unchanged when seen from the wider multicast infrastructure. unchanged when seen from the wider multicast infrastructure.
4.2.1. Considerations for PIM-SM on the Upstream 4.2.1. Considerations for PIM-SM on the Upstream
A mobile source that transmits data via an MLD proxy will not be A mobile source that transmits data via an MLD proxy will not be
directly connected to a PIM Designated Router as discussed in directly connected to a PIM Designated Router as discussed in
Section 3.2.3.1. Countermeasures apply correspondingly. Section 3.2.3.1. Countermeasures apply correspondingly.
A PIM Designated Router that is connected to MLD proxies via A PIM Designated Router that is connected to MLD proxies via
individual IP-tunnel interfaces will experience invalid PIM source individual IP-tunnel interfaces will experience invalid PIM source
states on handover. In some implementations of PIM-SM this could states on handover. In some implementations of PIM-SM this could
lead to interim packet loss (see Section Section 3.2.3.1). This lead to an interim packet loss (see Section Section 3.2.3.1). This
problem can be mitigated by aggregating proxies on a lower layer. problem can be mitigated by aggregating proxies on a lower layer.
4.2.2. SSM Considerations 4.2.2. SSM Considerations
Source-specific subscriptions invalidate with routes, whenever the Source-specific subscriptions invalidate with routes, whenever the
source moves from or to the MAG/proxy of a subscriber. Multicast source moves from or to the MAG/proxy of a subscriber. Multicast
forwarding states will rebuild with unicast route changes. However, forwarding states will rebuild with unicast route changes. However,
this may lead to noticeable service disruptions for locally this may lead to noticeable service disruptions for locally
subscribed nodes. subscribed nodes.
4.3. PIM-SM 4.3. PIM-SM at MAGs
The full-featured multicast routing protocol PIM-SM MAY be deployed The full-featured multicast routing protocol PIM-SM MAY be deployed
in the access network for providing multicast services in parallel to in the access network for providing multicast services in parallel to
unicast routes. Throughout this section, it is assumed that the unicast routes. Throughout this section, it is assumed that the
PMIPv6 mobility domain is part of a single PIM-SM multicast routing PMIPv6 mobility domain is part of a single PIM-SM multicast routing
domain with PIM-SM routing functions present at all MAGs and all domain with PIM-SM routing functions present at all MAGs and all
LMAs. The PIM routing instance at a MAG SHALL then serve as the LMAs. The PIM routing instance at a MAG SHALL then serve as the
Designated Router (DR) for all directly attached Mobile Nodes. For Designated Router (DR) for all directly attached Mobile Nodes. For
expediting handover operations, it is advisable to position PIM expediting handover operations, it is advisable to position PIM
Rendezvous Points (RPs) in the core of the PMIPv6 network domain. Rendezvous Points (RPs) in the core of the PMIPv6 network domain.
skipping to change at page 14, line 52 skipping to change at page 13, line 14
In this scenario, PIM-SM will rely on a Multicast Routing Information In this scenario, PIM-SM will rely on a Multicast Routing Information
Base (MRIB) that is generated independently of the policy-based Base (MRIB) that is generated independently of the policy-based
routing rules of PMIPv6. The granularity of mobility-related routing routing rules of PMIPv6. The granularity of mobility-related routing
locators required in PIM depends on the complexity (phases) of its locators required in PIM depends on the complexity (phases) of its
deployment. deployment.
The following information is needed for all phases of PIM. The following information is needed for all phases of PIM.
o All routes to networks and nodes (including RPs) that are not o All routes to networks and nodes (including RPs) that are not
mobile members of the PMIPv6 domain MUST be defined consistently mobile members of the PMIPv6 domain MUST be defined consistently
among PIM routers and remain uneffected by node mobility. The among PIM routers and MUST remain uneffected by node mobility.
setup of these general routes is expected to follow the topology The setup of these general routes is expected to follow the
of the operator network and is beyond the scope of this document. topology of the operator network and is beyond the scope of this
document.
The following route entries are required at a PIM-operating MAG when The following route entries are required at a PIM-operating MAG when
phases two or three of PIM, or PIM-SSM are in operation. phases two or three of PIM, or PIM-SSM are in operation.
o All MNs that are directly attached to the MAG generate local o Local routes to the Home Network Prefixes (HNPs) of all MNs
routes to their Home Network Prefixes (HNPs) at the corresponding associated with their corresponding point-to-point attachments
point-to-point attachments that MUST be included into the local that MUST be included in the local MRIB.
MRIB.
o All routes to MNs that are attached to distant MAGs of the PMIPv6 o All routes to MNs that are attached to distant MAGs of the PMIPv6
domain point towards their corresponding LMAs. These routes MUST domain point towards their corresponding LMAs. These routes MUST
be made available in the MRIB of all PIM routers (except for the be made available in the MRIB of all PIM routers (except for the
local MAG of attachment), but MAY be eventually expressed by an local MAG of attachment), but MAY be eventually expressed by an
appropriate default entry. appropriate default entry.
4.3.2. Operations of PIM in Phase One 4.3.2. Operations of PIM in Phase One
A new mobile source S will transmit multicast data of group G towards A new mobile source S will transmit multicast data of group G towards
its MAG of attachment. Acting as a PIM DR, the access gateway will its MAG of attachment. Acting as a PIM DR, the access gateway will
unicast-encapsulate the multicast packets and forward the data to the unicast-encapsulate the multicast packets and forward the data to the
Virtual Interface (VI) with encapsulation target RP(G), a process Virtual Interface (VI) with encapsulation target RP(G), a process
known as PIM source registering. The RP will decapsulate and known as PIM source registering. The RP will decapsulate and
natively forward the packets down the RP-based distribution tree natively forward the packets down the RP-based distribution tree
towards (mobile and stationary) subscribers. towards (mobile and stationary) subscribers.
On handover, the point-to-point link connecting the mobile source to On handover, the point-to-point link connecting the mobile source to
the old MAG will go down and all (S,*) flows terminate. In response, the old MAG will go down and all (S,*) flows terminate. In response,
the previous DR (MAG) deactivates the data encapsulation channels for the previous DR (MAG) deactivates the data encapsulation channels for
the transient source (e.g., all DownstreamJPState(S,*,VI) are set to the transient source (i.e., all DownstreamJPState(S,*,VI) are set to
NoInfo state). After reattaching and completing unicast handover NoInfo state). After reattaching and completing unicast handover
negotiations, the mobile source can continue to transmit multicast negotiations, the mobile source can continue to transmit multicast
packets, while being treated as a new source at its new DR (MAG). packets, while being treated as a new source at its new DR (MAG).
Source register encapsulation will be immediately initiated, and Source register encapsulation will be immediately initiated, and
(S,G) data continue to flow natively down the (*,G) RP-based tree. (S,G) data continue to flow natively down the (*,G) RP-based tree.
Source handover management in PIM phase one admits low complexity and Source handover management in PIM phase one admits low complexity and
remains transparent to receivers. In addition, the source register remains transparent to receivers. In addition, the source register
tunnel management of PIM is a fast protocol operation and little tunnel management of PIM is a fast protocol operation and little
overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be
configured to not initiated (S,G) shortest path tress for mobile configured to not initiated (S,G) shortest path tress for mobile
sources, and thus remain in phase one of the protocol. The price to sources, and thus remain in phase one of the protocol. The price to
pay for such simplified deployment lies in possible routing detours pay for such simplified deployment lies in possible routing detours
by an overall RP-based packet distribution. by an overall RP-based packet distribution.
4.3.3. Operations of PIM in Phase Two 4.3.3. Operations of PIM in Phase Two
After receiving source register packets, a PIM RP eventually will After receiving source register packets, a PIM RP eventually will
initiated a source-specific Join for creating a shortest path tree to initiate a source-specific Join for creating a shortest path tree to
the (mobile) source S, and issue a source register stop at the native the (mobile) source S, and issue a source register stop at the native
arrival of data from S. For initiating an (S,G) tree, the RP, as well arrival of data from S. For initiating an (S,G) tree, the RP, as well
as all intermediate routers, require route entries for MN's HNP that as all intermediate routers, require route entries for the HNP of the
- unless the RP coincides with the MAG of S - point towards the MN that - unless the RP coincides with the MAG of S - point towards
corresponding LMA of S. Consequently, the (S,G) tree will proceed the corresponding LMA of S. Consequently, the (S,G) tree will proceed
from the RP via the (stable) LMA, the LMA-MAG tunnel to the mobile from the RP via the (stable) LMA, down the LMA-MAG tunnel to the
source. This tree can be of lesser routing efficiency than the PIM mobile source. This tree can be of lesser routing efficiency than
source register tunnel established in phase one, but provides the the PIM source register tunnel established in phase one, but provides
advantage of immediate data delivery to receivers that share a MAG the advantage of immediate data delivery to receivers that share a
with S. MAG with S.
On handover, the mobile source reattaches to a new MAG (DR), and On handover, the mobile source reattaches to a new MAG (DR), and
PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
point of attachment. However, in the absence of a corresponding point of attachment. However, in the absence of a corresponding
multicast forwarding state, the new DR will treat S as a new source multicast forwarding state, the new DR will treat S as a new source
and initiate a source registering of PIM phase one with the RP. In and initiate a source registering of PIM phase one with the RP. In
response, the PIM RP will recognize the known source at a new response, the PIM RP will recognize the known source at a new
(tunnel) interface. A PIM RP implementation compliant with this (tunnel) interface immediately responds with a register stop. As the
change can proceed as follows. The RP immediately responds with a
register stop, when it receives a register from the new MAG. As the
RP had joined the shortest path tree to receive from the source via RP had joined the shortest path tree to receive from the source via
the LMA, the tree is persistently updated by joins transmitted the LMA, it will see an RPF change when data arrives at a new
towards the new MAG on a path via the LMA. In proceeding this way, a interface. Implementation-dependent, this can trigger an update of
quick recovery of PIM transition from phase one to two will be the PIM MRIB and trigger a new PIM Join message. Otherwise, the tree
performed per handover. is periodically updated by Joins transmitted towards the new MAG on a
path via the LMA. In proceeding this way, a quick recovery of PIM
transition from phase one to two will be performed per handover.
4.3.4. Operations of PIM in Phase Three 4.3.4. Operations of PIM in Phase Three
In response to an exceeded threshold of packet transmission, DRs of In response to an exceeded threshold of packet transmission, DRs of
receivers eventually will initiated a source-specific Join for receivers eventually will initiated a source-specific Join for
creating a shortest path tree to the (mobile) source S, thereby creating a shortest path tree to the (mobile) source S, thereby
transitioning PIM into the final short-cut phase three. For all transitioning PIM into the final short-cut phase three. For all
receivers not sharing a MAG with S, this (S,G) tree will proceed from receivers not sharing a MAG with S, this (S,G) tree will range from
the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
mobile source. This tree is of higher routing efficiency than mobile source. This tree is of higher routing efficiency than
established in the previous phase two, but need not outperform the established in the previous phase two, but need not outperform the
PIM source register tunnel established in phase one. It provides the PIM source register tunnel established in phase one. It provides the
advantage of immediate data delivery to receivers that share a MAG advantage of immediate data delivery to receivers that share a MAG
with S. with S.
On handover, the mobile source reattaches to a new MAG (DR), and On handover, the mobile source reattaches to a new MAG (DR), and
PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
point of attachment. However, in the absence of a corresponding point of attachment. However, in the absence of a corresponding
multicast forwarding state, the new DR will treat S as a new source multicast forwarding state, the new DR will treat S as a new source
and initiate a source registering of PIM phase one. A PIM and initiate a source registering of PIM phase one. A PIM
implementation compliant with this change can recover phase three implementation compliant with this change can recover phase three
states in the following way. First, the RP recovers to phase two as states in the following way. First, the RP recovers to phase two as
described in the previous section, but - being unaware of the LMA in described in the previous section, and will not forward data arriving
the role of a static mobility anchor - needs to forward data packets via the source register tunnel. Tree mainenance eventually triggered
that arrived via the source register tunnel down the RP-base tree by the RPF change (see Section 4.3.3) will generate proper states for
towards receivers. Such packets will trigger updates of phase three a native forwarding from the new MAG via the LMA. Thereafter,
shortest path trees at the DRs of the receivers. Meanwhile packets packets arriving at the LMA without source register encapsulation are
arriving at the LMA without source register encapsulation are
forwarded natively along the shortest path tree towards receivers. forwarded natively along the shortest path tree towards receivers.
In consequence, the PIM transition from phase one to two and three In consequence, the PIM transition from phase one to two and three
will be quickly recovered per handover, but still leads to an will be quickly recovered per handover, but still leads to an
enhanced signaling load and repeated delay variations. enhanced signaling load and intermediate packet loss.
4.3.5. PIM-SSM Considerations 4.3.5. PIM-SSM Considerations
Source-specific Joins of receivers will guide PIM to operate in SSM Source-specific Joins of receivers will guide PIM to operate in SSM
mode and lead to an immediate establishment of source-specific mode and lead to an immediate establishment of source-specific
shortest path trees. Such (S,G) trees will equal the distribution shortest path trees. Such (S,G) trees will equal the distribution
system of PIM's final phase three (see Section 4.3.4). However, on system of PIM's final phase three (see Section 4.3.4). However, on
handover and in the absence of RP-based data distribution, SSM data handover and in the absence of RP-based data distribution, SSM data
delivery cannot be resumed via source registering as in PIM phase delivery cannot be resumed via source registering as in PIM phase
one. Consequently, data packets transmitted after a handover will be one. Consequently, data packets transmitted after a handover will be
skipping to change at page 22, line 12 skipping to change at page 20, line 14
the PMIPv6 domain will not actively terminate group membership prior the PMIPv6 domain will not actively terminate group membership prior
to departure. to departure.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank (in alphabetical order) Luis M. The authors would like to thank (in alphabetical order) Luis M.
Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong,
Jouni Korhonen, He-Wu Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Jouni Korhonen, He-Wu Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian
Wu, Zhi-Wei Yan for advice, help and reviews of the document. Wu, Zhi-Wei Yan for advice, help and reviews of the document.
Funding by the German Federal Ministry of Education and Research Funding by the German Federal Ministry of Education and Research
within the G-LAB Initiative (project HAMcast) is gratefully within the G-LAB Initiative (projects HAMcast, Mindstone and SAFEST)
acknowledged. is gratefully acknowledged.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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.
[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
October 1999. 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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[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
("IGMP/MLD Proxying")", RFC 4605, August 2006. /MLD Proxying")", RFC 4605, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
9.2. Informative References 9.2. Informative References
[I-D.ietf-multimob-pmipv6-ropt] [I-D.ietf-multimob-pmipv6-ropt]
Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y.
Kim, "Multicast Mobility Routing Optimizations for Proxy Kim, "Multicast Mobility Routing Optimizations for Proxy
Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-03 (work in Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-07 (work in
progress), February 2013. progress), July 2013.
[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
skipping to change at page 24, line 48 skipping to change at page 23, line 5
signaling, i.e. in IGMPv2/MLDv1 only domains. signaling, i.e. in IGMPv2/MLDv1 only domains.
In typical deployment scenarios, specific group services (channels) In typical deployment scenarios, specific group services (channels)
could be either associated with selected uplinks to remote LMAs, could be either associated with selected uplinks to remote LMAs,
while a (*,*) default subscription entry (in the last table line) is while a (*,*) default subscription entry (in the last table line) is
bound to a local routing interface, or selected groups are configured bound to a local routing interface, or selected groups are configured
as local services first, while a (*,*) default entry (in the last as local services first, while a (*,*) default entry (in the last
table line) points to a remote uplink that provides the general table line) points to a remote uplink that provides the general
multicast support. multicast support.
Appendix B. Evaluation of Traffic Flows Appendix B. Change Log
TODO The following changes have been made from version draft-ietf-
multimob-pmipv6-source-03:
Appendix C. Change Log 1. Fixed issues in Section Section 4.3 (PIM phase two and three
transistion) according to WG feedback.
The following changes have been made from version 2. Editorial improvements, resolved nits.
draft-ietf-multimob-pmipv6-source-02:
3. Updated references.
The following changes have been made from version draft-ietf-
multimob-pmipv6-source-02:
1. Added clarifications and details as requested by the working 1. Added clarifications and details as requested by the working
group, resolved nits. group, resolved nits.
2. Moved Multiple Upstream MLD Proxy to Appendix in response to WG 2. Moved Multiple Upstream MLD Proxy to Appendix in response to WG
desire. desire.
3. Updated references. 3. Updated references.
The following changes have been made from version The following changes have been made from version draft-ietf-
draft-ietf-multimob-pmipv6-source-01: multimob-pmipv6-source-01:
1. Added clarifications and details as requested by the working 1. Added clarifications and details as requested by the working
group, resolved nits. group, resolved nits.
2. Detailed out operations of Multiple Upstream MLD Proxies. 2. Detailed out operations of Multiple Upstream MLD Proxies.
3. Clarified operations of MLD proxies with peering links. 3. Clarified operations of MLD proxies with peering links.
4. Many editorial improvements. 4. Many editorial improvements.
5. Updated references. 5. Updated references.
The following changes have been made from version The following changes have been made from version draft-ietf-
draft-ietf-multimob-pmipv6-source-00: multimob-pmipv6-source-00:
1. Direct routing with PIM-SM and PIM-SSM has been added. 1. Direct routing with PIM-SM and PIM-SSM has been added.
2. PMIP synchronization with PIM added for improved handover. 2. PMIP synchronization with PIM added for improved handover.
3. Direct routing with BIDIR-PIM has been added. 3. Direct routing with BIDIR-PIM has been added.
4. MLD Proxy extensions requirements added. 4. MLD Proxy extensions requirements added.
5. Peering of MLD Proxies added. 5. Peering of MLD Proxies added.
skipping to change at page 26, line 18 skipping to change at page 24, line 26
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
Shuai Gao Shuai Gao
Beijing Jiaotong University Beijing Jiaotong University
Beijing, Beijing
China China
Phone:
Fax:
Email: shgao@bjtu.edu.cn Email: shgao@bjtu.edu.cn
URI:
Hong-Ke Zhang Hong-Ke Zhang
Beijing Jiaotong University Beijing Jiaotong University
Beijing, Beijing
China China
Phone:
Fax:
Email: hkzhang@bjtu.edu.cn Email: hkzhang@bjtu.edu.cn
URI:
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
 End of changes. 52 change blocks. 
181 lines changed or deleted 178 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/