draft-ietf-multimob-pmipv6-source-00.txt   draft-ietf-multimob-pmipv6-source-01.txt 
MULTIMOB Group T C. Schmidt, Ed. MULTIMOB Group T C. Schmidt, Ed.
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: Standards Track S. Gao Intended status: Standards Track S. Gao
Expires: July 12, 2012 H. Zhang Expires: January 17, 2013 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
January 9, 2012 July 16, 2012
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-00 draft-ietf-multimob-pmipv6-source-01
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. Mobile sources Proxy Mobile IPv6 domains for all three scenarios. Protocol
always remain agnostic of multicast mobility operations. optimizations for synchronizing PMIPv6 with PIM, as well as extended
MLD Proxy functions are presented. Mobile sources always remain
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 46 skipping to change at page 1, line 48
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 July 12, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 19 skipping to change at page 3, line 7
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 4 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . . 8 3.2. Base Solution for Source Mobility: Details . . . . . . . . 9
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 8 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 8 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Efficiency of the Distribution System . . . . . . . . 10 3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 10 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 11
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 11 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12
4.2.1. PIM-SM Considerations . . . . . . . . . . . . . . . . 12 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 12 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 13
4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. BIDIR PIM . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 14
5. Extended Source Mobility Schemes in PMIPv6 . . . . . . . . . . 13 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . . 14
5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 13 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17
Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 16 5. Extended MLD Proxy Functions for Optimized Source Mobility
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 18
5.1.1. Operations for Local Multicast Sources . . . . . . . . 19
5.1.2. Operations for Local Multicast Subscribers . . . . . . 19
5.2. Peering Function for MLD Proxies . . . . . . . . . . . . . 19
5.2.1. Operations at the Multicast Sender . . . . . . . . . . 19
5.2.2. Operations at the Multicast Listener . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 23
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 10, line 30 skipping to change at page 11, line 30
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
MAG. MAG.
4. Direct Multicast Routing 4. Direct Multicast Routing
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.zuniga-multimob-pmipv6-ropt]. In these cases, routing system [I-D.ietf-multimob-pmipv6-ropt]. In these cases, the
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 Section 5 for a further
discussion). discussion).
4.1. Overview 4.1. Overview
skipping to change at page 11, line 50 skipping to change at page 12, line 50
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
the multicast routing protocol in use, in the following described for the multicast routing protocol in use, in the following described for
common protocols. common protocols.
4.2. MLD Proxies at MAGs 4.2. MLD Proxies at MAGs
In a PMIPv6 domain, single MLD proxy instances can be deployed at In a PMIPv6 domain, single MLD proxy instances can be deployed at
each MAG to enable multicast service at the access (see Figure 3 (a) each MAG that enable multicast service at the access via an uplink to
). To avoid service disruptions on handovers, the uplinks of all a multicast service infrastructure (see Figure 3 (a) ). To avoid
proxies SHOULD be adjacent to the same next-hop multicast router. service disruptions on handovers, the uplinks of all proxies SHOULD
be adjacent to the same next-hop multicast router. This can either
This can either be achieved by arranging proxies within a flat access be achieved by arranging proxies within a flat access network, or by
network, or by upstream tunnels that terminate at a common multicast upstream tunnels that terminate at a common multicast router.
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 at 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, the aggregated listener reports of the previous proxy. In general,
mobile source remains unchanged when seen from the wider multicast traffic from the mobile source continues to be transmitted via the
infrastructure. same next-hop router using the same source address and thus remains
unchanged when seen from the wider multicast infrastructure.
4.2.1. PIM-SM Considerations 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. This problem can be mitigated by aggregating states on handover. This problem can be mitigated by aggregating
proxies on a lower layer. 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
TODO The full-featured multicast routing protocol PIM-SM MAY be deployed
in the access network for providing multicast services in parallel to
unicast routes. Throughout this section, it is assumed that the
PMIPv6 mobility domain is part of a single PIM-SM multicast routing
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
Designated Router (DR) for all directly attached Mobile Nodes. For
expediting handover operations, it is advisable to position PIM
Rendezvous Points (RPs) in the core of the PMIPv6 network domain.
However, regular IP routing tables need not be present in a PMIPv6
deployment, and additional effort is required to establish reverse
path forwarding rules as required by PIM-SM.
4.4. BIDIR PIM 4.3.1. Routing Information Base for PIM-SM
TODO In this scenario, PIM-SM will rely on a Multicast Routing Information
Base (MRIB) that is generated independently of the policy-based
routing rules of PMIPv6. The granularity of mobility-related routing
locators required in PIM depends on the complexity (phases) of its
deployment.
5. Extended Source Mobility Schemes in PMIPv6 The following information is needed for all phases of PIM.
In this section, specific optimization approaches to multicast source o All routes to networks and nodes (including RPs) that are not
mobility are introduced. mobile members of the PMIPv6 domain MUST be defined consistently
among PIM routers and remain uneffected by node mobility. The
setup of these general routes is expected to follow the 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
phases two or three of PIM, or PIM-SSM are in operation.
o All MNs that are directly attached to the MAG generate local
routes to their Home Network Prefixes (HNPs) at the corresponding
point-to-point attachments that MUST be included into the local
MRIB.
o All routes to MNs that are attached to distant MAGs of the PMIPv6
domain point towards their corresponding LMAs. These routes MUST
be made available in the MRIB of all PIM routers (except for the
local MAG of attachment), but MAY be eventually expressed by an
appropriate default entry.
4.3.2. Operations of PIM in Phase One
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
unicast-encapsulate the multicast packets and forward the data to the
Virtual Interface (VI) with encapsulation target RP(G), a process
known as PIM source registering. The RP will decapsulate and
natively forward the packets down the RP-based distribution tree
towards (mobile and stationary) subscribers.
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 previous DR (MAG) deactivates the data encapsulation channels for
the transient source (e.g., all DownstreamJPState(S,*,VI) are set to
NoInfo state). After reattaching and completing unicast handover
negotiations, the mobile source can continue to transmit multicast
packets, while being treated as a new source at its new DR (MAG).
Source register encapsulation will be immediately initiated, and
(S,G) data continue to flow natively down the (*,G) RP-based tree.
Source handover management in PIM phase one admits low complexity and
remains transparent to receivers. In addition, the source register
tunnel management of PIM is a fast protocol operation and little
overhead can be expected thereof. In a PMIPv6 deployment, PIM RPs
MAY be configured to not initiated (S,G) shortest path tress for
mobile sources, and thus remain in phase one of the protocol. The
price to pay for such simplified deployment lies in possible routing
detours by an overall RP-based packet distribution even in those
cases, where mobile senders and receivers are attached to the same
access router.
4.3.3. Operations of PIM in Phase Two
After receiving source register packets, a PIM RP eventually will
initiated a source-specific Join for creating a shortest path tree to
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
as all intermediate routers, require route entries for MN's HNP that
- unless the RP coincides with the MAG of S - point towards 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
source. This tree can be of lesser routing efficiency than the PIM
source register tunnel established in phase one, but provides the
advantage of immediate data delivery to receivers that share a MAG
with S.
On handover, the mobile source reattaches to a new MAG (DR), and
PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
point of attachment. However, in the absence of a corresponding
multicast forwarding state, the new DR will treat S as a new source
and initiate a source registering of PIM phase one. In consequence,
the PIM transition from phase one to two will be iterated per
handover, leading to an enhanced signaling load and repeated delay
variations.
4.3.4. Operations of PIM in Phase Three
In response to an exceeded threshold of packet transmission, DRs of
receivers eventually will initiated a source-specific Join for
creating a shortest path tree to the (mobile) source S, thereby
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
the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
mobile source. This tree is of higher routing efficiency than
established in the previous phase two, but need not outperform the
PIM source register tunnel established in phase one. It provides the
advantage of immediate data delivery to receivers that share a MAG
with S.
On handover, the mobile source reattaches to a new MAG (DR), and
PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
point of attachment. However, in the absence of a corresponding
multicast forwarding state, the new DR will treat S as a new source
and initiate a source registering of PIM phase one. In consequence,
the PIM transition from phase one to two and three will be iterated
per handover, leading to an enhanced signaling load and repeated
delay variations.
4.3.5. PIM-SSM Considerations
Source-specific Joins of receivers will guide PIM to operate in SSM
mode and lead to an immediate establishment of source-specific
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
handover and in the absence of RP-based data distribution, SSM data
delivery cannot be resumed via source registering as in PIM phase
one. Consequently, data packets transmitted after a handover will be
discarded at the MAG until regular tree maintenance has re-
established the (S,G) forwarding state at the new MAG.
4.3.6. Handover Optimizations for PIM
Source-specific shortest path trees are constructed in PIM-SM (phase
two and three), and in PIM-SSM that follow LMA-MAG tunnels towards a
source. As PIM remains unaware of source mobility management, these
trees invalidate under handovers with each tunnel re-establishment at
a new MAG. Regular tree maintenance of PIM will recover the states,
but remains unsynchronized and too slow to seamlessly preserve PIM
data dissemination.
A method to quickly recover PIM (S,G) trees under handover SHOULD
synchronize multicast state maintenance with unicast handover
operations and MAY proceed as follows. On handover, an LMA reads all
(S,G) Join states from its corresponding tunnel interface and
identifies those source addresses S_i that match moving HNPs. After
re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join
states with the new tunnel endpoint and immediately trigger a state
maintenance (PIM Join) message. In proceeding this way, the source-
specific PIM states are transferred to the new tunnel end point and
propagated to the new MAG in synchrony with unicast handover
procedures.
4.4. BIDIR-PIM
BIDIR-PIM MAY be deployed in the access network for providing
multicast services in parallel to unicast routes. Throughout this
section, it is assumed that the PMIPv6 mobility domain is part of a
single BIDIR-PIM multicast routing domain with BIDIR-PIM routing
functions present at all MAGs and all LMAs. The PIM routing instance
at a MAG SHALL then serve as the Designated Forwarder (DF) for all
directly attached Mobile Nodes. For expediting handover operations,
it is advisable to position BIDIR-PIM Rendezvous Point Addresses
(RPAs) in the core of the PMIPv6 network domain. As regular IP
routing tables need not be present in a PMIPv6 deployment, reverse
path forwarding rules as required by BIDIR-PIM need to be
established.
4.4.1. Routing Information Base for BIDIR-PIM
In this scenario, BIDIR-PIM will rely on a Multicast Routing
Information Base (MRIB) that is generated independently of the
policy-based routing rules of PMIPv6. The following information is
needed.
o All routes to networks and nodes (including RPAs) that are not
mobile members of the PMIPv6 domain MUST be defined consistently
among BIDIR-PIM routers and remain uneffected by node mobility.
The setup of these general routes is expected to follow the
topology of the operator network and is beyond the scope of this
document.
4.4.2. Operations of BIDIR-PIM
BIDIR-PIM will establish spanning trees across its network domain in
conformance to its preconfigured RPAs and the routing information
provided. Multicast data transmitted by a mobile source will
immediately be forwarded by its DF (MAG) onto the spanning group tree
without further protocol operations.
On handover, the mobile source re-attaches to a new MAG (DF), which
completes unicast network configurations. Thereafter, the source can
immediately proceed with multicast packet transmission onto the pre-
established distribution tree. BIDIR-PIM does neither require
protocol signaling nor additional reconfiguration delays to adapt to
source mobility and can be considered the protocol of choice for
mobile multicast operations in the access. As multicast streams
always flow up to the Rendezvous Point Link, some care should be
taken to configure RPAs compliant with network capacities.
5. Extended MLD Proxy Functions for Optimized Source Mobility in PMIPv6
A deployment of MLD Proxies (see [RFC4605]) at MAGs has proven a
useful and appropriate approach to multicast in PMIPv6, see
[RFC6224], [I-D.ietf-multimob-pmipv6-ropt]. However, unmodified
standard solutions go along with significant performance degradation
for mobile senders as discussed along the lines of this document. To
overcome these deficits, optimizing approaches to multicast source
mobility are introduced in this section. In particular, uplink
capabilities of MLD proxies are extended to allow for rapid,
optimized multicast traffic flows from mobile sources.
Solutions that extend MLD Proxies by additional uplinking functions
need to comply to the following requirements.
Prevention of Routing Loops In the absence of a full-featured
routing logic at an MLD Proxy, simple and locally decidable rules
need to prevent source traffic from traversing the network in
loops as potentially enabled by multiple uplinks.
Unique coverage of receivers Listener functions at Proxies require
simple, locally decidable rules to initiate a unique delivery of
multicast packets for all receivers.
Following different techniques, these requirements are met in the
following solutions.
5.1. Multiple Upstream Interface Proxy 5.1. Multiple Upstream Interface Proxy
Although multicast communication can be enabled in PMIPv6 domains by In this section, we define upstream extensions for an MLD proxy.
deploying MLD Proxy functions at MAG, some disadvantages still exist. Multiple proxy instances deployed at a single MAG (see Section 3) can
Firstly, for a proxy device performing IGMP/MLD-based forwarding has be avoided by adding multiple upstream interfaces to a single MLD
a single upstream interface and one or more downstream interfaces as Proxy. In a typical PMIPv6 deployment, each upstream of a single
described in RFC4605, there should be many MLD Proxy functions Proxy instance can interconnect one of the LMAs. With such ambiguous
deployed at one MAG, which is complicated and then is difficult for upstream options, appropriate forwarding rules MUST be supplied to
implementation and management. And then when the multicast packets
arrive at the MAG running multiple parallel MLD proxy functions,
there may be confusions for the data if there is no extra processing
or filtering scheme at the MAG. In addition, the route optimization
issue is still up in the air, that is, for a mobile receiver and a
source on the same MAG using different LMAs, the traffic has to go up
to one 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 MAG. Therefore, the MLD Proxy function should be extended to
accommodate the PMIPv6 protocol. As same as described in [RFC6224]
and this document (s. abobe), the MLD proxy functions are deployed at
the MAG, while only one MLD Proxy function is required to run at the
MAG and multiple upstream interfaces can be set for the MLD Proxy
instance, which is called Multi-Upstream Interfaces MLD Proxy
(MUIMP).
.... TODO details. o unambiguously guide traffic forwarding from directly attached
mobile sources, and
o lead listener reports to initiating unique traffic subscriptions.
This can be achieved by a complete set of source- and group-specific
filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces.
These filters MAY be derived in parts from PMIPv6 routing policies,
and can include a default behavior (e.g., (*,*)).
TODO details
5.1.1. Operations for Local Multicast Sources
Packets from a locally attached multicast source will be forwarded to
all downstream interfaces with appropriate subscriptions, as well as
up the interface with the matching source-specific filter.
TODO details
5.1.2. Operations for Local Multicast Subscribers
Multicast listener reports are group-wise aggregated by the MLD
proxy. The aggregated report is issued to the upstream interface
with matching group-specific filter.
TODO details
5.2. Peering Function for MLD Proxies
In this section, we define a peering interface for MLD proxies that
allows for a direct data exchange of locally attached multicast
sources. Such peering interfaces can be configured - as a direct
link or a bidirectional tunnel - between any two proxy instances
(locally deployed as in [RFC6224] or remotely) and remains a silent
virtual link in regular proxy operations. Data on such link is
exchanged only in cases, where one peering proxy connects to a source
of multicast traffic, which the other peering proxy actively
subscribes to. Operations are defined for ASM and SSM, but provide
superior performance in SSM mode.
5.2.1. Operations at the Multicast Sender
An MLD Proxy with peering interfaces will install and maintain source
filters at its peering links that will restrict data transmission to
those packets that originate from a locally attached source. In this
way, a multihop forwarding on peering links is prevented. Multicast
packets that arrive from the upstream interface of the Proxy are thus
be forwarded only to regular downstream interfaces with appropriate
subscription states.
Multicast traffic arriving from a locally attached source will be
forwarded to the regular upstream interface and all downstreams with
appropriate subscription states (i.e., regular Proxy operations). In
addition, local multicast packets are transferred to those peering
interfaces with appropriate subscription states. As seen from the
sender side, peering interfaces act as restricted downstream
interfaces.
5.2.2. Operations at the Multicast Listener
From the listener side, peering interfaces appear as preferred
upstream links. Thus an MLD Proxy with peering interconnects will
provide several interfaces for pulling remote traffic: the regular
upstream and the peerings. Traffic arriving from any of the peering
links will normally also be available from the upstream. To prevent
duplicate traffic from arriving at the listener side, the Proxy
o MAY delay aggregated reports to the upstream, and
o MUST apply appropriate filters to exclude duplicate streams.
In detail, it first issues listener reports (in parallel) to its
peering links, which are only one (virtual) hop apart. Whenever the
expected traffic (e.g., SSM channels) does not completely arrive from
the peerings after a waiting time (default: 10 ms), additional
(complementary, in the case of SSM) reports are sent to the standard
upstream interface.
After the arrival of traffic from peering links, an MLD proxy MUST
install source filters at the upstream in the following way.
ASM In the presence of Any Source Multicast (IGMPv2/MLDv1), only,
the Proxy cannot signal source filtering to its upstream.
Correspondingly, it applies (S,*) ingress filters at its upstream
interface. It is noteworthy that unwanted traffic is still
replicated to the proxy via the access network.
SSM In the presence of source-specific signaling (IGMPv3/MLDv2), the
upstream interface is set to (S,*) exclude mode for all sources S
seen in traffic of the peering links. The corresponding source-
specific signaling will prevent duplicate traffic forwarding
throughout the access network.
In proceeding this way, multicast group data arrive from peering
interfaces first, while only peer-wise unavailable traffic is
retrieved from the regular upstream interface.
6. IANA Considerations 6. IANA Considerations
TODO. TODO.
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
skipping to change at page 14, line 26 skipping to change at page 21, line 38
controls at replicators MAY be required to protect the agents and the controls at replicators MAY be required to protect the agents and the
downstream networks. In particular, MLD proxy implementations at downstream networks. In particular, MLD proxy implementations at
MAGs SHOULD carefully procure for automatic multicast state MAGs SHOULD carefully procure for automatic multicast state
extinction on the departure of MNs, as mobile multicast listeners in extinction on the departure of MNs, as mobile multicast listeners in
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) Muhamma Omer The authors would like to thank (in alphabetical order) Muhamma Omer
Farooq, Aaron Feng, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu
Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Wu, Zhi-Wei Yan for Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Wu, Zhi-Wei Yan for
advice, help and reviews of the document. Funding by the German advice, help and reviews of the document. Funding by the German
Federal Ministry of Education and Research within the G-LAB Federal Ministry of Education and Research within the G-LAB
Initiative (project HAMcast) is gratefully acknowledged. Initiative (project HAMcast) 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
skipping to change at page 15, line 29 skipping to change at page 22, line 40
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.zuniga-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-zuniga-multimob-pmipv6-ropt-01 (work Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-00 (work in
in progress), October 2011. progress), March 2012.
[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 16, line 14 skipping to change at page 23, line 22
Appendix A. Evaluation of Traffic Flows Appendix A. Evaluation of Traffic Flows
TODO TODO
Appendix B. Change Log Appendix B. Change Log
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-source-00: draft-ietf-multimob-pmipv6-source-00:
1. Direct routing with PIM-SM and PIM-SSM has been added.
2. PMIP synchronization with PIM added for improved handover.
3. Direct routing with BIDIR-PIM has been added.
4. MLD Proxy extensions requirements added.
5. Peering of MLD Proxies added.
6. First sketch of multiple upstream proxy added.
7. Editorial improvements.
8. Updated references.
Authors' Addresses Authors' Addresses
Thomas C. Schmidt Thomas C. Schmidt
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg 20099 Hamburg 20099
Germany Germany
Email: schmidt@informatik.haw-hamburg.de Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt URI: http://inet.cpt.haw-hamburg.de/members/schmidt
 End of changes. 23 change blocks. 
80 lines changed or deleted 412 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/