draft-ietf-multimob-pmipv6-base-solution-04.txt   draft-ietf-multimob-pmipv6-base-solution-05.txt 
MULTIMOB Group T C. Schmidt MULTIMOB Group T C. Schmidt
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: BCP M. Waehlisch Intended status: BCP M. Waehlisch
Expires: January 13, 2011 link-lab & FU Berlin Expires: January 29, 2011 link-lab & FU Berlin
S. Krishnan S. Krishnan
Ericsson Ericsson
July 12, 2010 July 28, 2010
Base Deployment for Multicast Listener Support in PMIPv6 Domains Base Deployment for Multicast Listener Support in PMIPv6 Domains
draft-ietf-multimob-pmipv6-base-solution-04 draft-ietf-multimob-pmipv6-base-solution-05
Abstract Abstract
This document describes deployment options for activating multicast This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards. Similar to Home Agents in mobility and multicast protocol standards. Similar to Home Agents in
Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as
multicast subscription anchor points, while Mobile Access Gateways multicast subscription anchor points, while Mobile Access Gateways
provide MLD proxy functions. In this scenario, Mobile Nodes remain provide MLD proxy functions. In this scenario, Mobile Nodes remain
agnostic of multicast mobility operations. A support for mobile agnostic of multicast mobility operations. A support for mobile
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 13, 2011. This Internet-Draft will expire on January 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 5, line 10 skipping to change at page 5, line 10
via one of its downstream local (wireless) links. A multicast via one of its downstream local (wireless) links. A multicast
unaware MAG would simply discard these MLD messages. unaware MAG would simply discard these MLD messages.
To facilitate multicast in a PMIPv6 domain, an MLD proxy function To facilitate multicast in a PMIPv6 domain, an MLD proxy function
[RFC4605] needs to be deployed on the MAG that selects the tunnel [RFC4605] needs to be deployed on the MAG that selects the tunnel
interface corresponding to the MN's LMA for its upstream interface interface corresponding to the MN's LMA for its upstream interface
(cf., section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel (cf., section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel
interface defines an MLD proxy domain at the MAG, and it contains all interface defines an MLD proxy domain at the MAG, and it contains all
downstream links to MNs that share this specific LMA. According to downstream links to MNs that share this specific LMA. According to
standard proxy operations, MLD Report messages will be forwarded standard proxy operations, MLD Report messages will be aggregated and
under aggregation up the tunnel interface to its corresponding LMA. then forwarded up the tunnel interface to its corresponding LMA.
Serving as the designated multicast router or an additional MLD Serving as the designated multicast router or an additional MLD
proxy, the LMA will transpose any MLD message from a MAG into the proxy, the LMA will transpose any MLD message from a MAG into the
multicast routing infrastructure. Correspondingly, the LMA will multicast routing infrastructure. Correspondingly, the LMA will
create appropriate multicast forwarding states at its tunnel create appropriate multicast forwarding states at its tunnel
interface. Traffic arriving for subscribed groups will arrive at the interface. Traffic of the subscribed groups will arrive at the LMA,
LMA, and the LMA will forward this traffic according to its group/ and the LMA will forward this traffic according to its group/source
source states. In addition, the LMA will act as an MLD querier, states. In addition, the LMA will act as an MLD querier, seeing its
seeing its downstream tunnel interfaces as multicast enabled links. downstream tunnel interfaces as multicast enabled links.
At the MAG, MLD queries and multicast data will arrive on the At the MAG, MLD queries and multicast data will arrive on the
(tunnel) interface that is assigned to a group of access links as (tunnel) interface that is assigned to a group of access links as
identified by its Binding Update List (cf., section 6 of [RFC5213]). identified by its Binding Update List (cf., section 6.1 of
As specified for MLD proxies, the MAG will forward multicast traffic [RFC5213]). As specified for MLD proxies, the MAG will forward
and initiate related signaling down the appropriate access links to multicast traffic and initiate related signaling down the appropriate
the MNs. Hence all multicast-related signaling and the data traffic access links to the MNs. Hence all multicast-related signaling and
will transparently flow from the LMA to the MN on an LMA-specific the data traffic will transparently flow from the LMA to the MN on an
tree, which is shared among the multicast sources. LMA-specific tree, which is shared among the multicast sources.
In case of a handover, the MN (unaware of IP mobility) will not send In case of a handover, the MN (unaware of IP mobility) will not send
unsolicited MLD reports. Instead, the MAG is required to maintain unsolicited MLD reports. Instead, the MAG is required to maintain
group memberships in the following way. On observing a new MN on a group memberships in the following way. On observing a new MN on a
downstream access link, the MAG sends a General MLD Query. Based on downstream access link, the MAG sends a General MLD Query. Based on
its outcome and the multicast group states previously maintained at its outcome and the multicast group states previously maintained at
the MAG, a corresponding Report will be sent to the LMA aggregating the MAG, a corresponding Report will be sent to the LMA aggregating
group membership states according to the proxy function. Additional group membership states according to the proxy function. Additional
Reports can be omitted when the previously established multicast Reports can be omitted when the previously established multicast
forwarding states at the new MAG already cover the subscriptions of forwarding states at the new MAG already cover the subscriptions of
skipping to change at page 7, line 21 skipping to change at page 7, line 21
| | | | | | | | | |
| | Aggregated Join(G) | | | | Aggregated Join(G) | |
| +================================================>| | +================================================>|
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
| |<================================================+ | |<================================================+
| | | | | | | | | |
| Mcast Data | Mcast Data | | | | Mcast Data | Mcast Data | | |
|<---------------+--------------->| | | |<---------------+--------------->| | |
| | | | | | | | | |
| < Movement to MAG2 & PMIP Binding Update > | | < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | | | | | | |
| | |--- Rtr Sol -->| | | | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| | | | |<-- Rtr Adv ---| |
| | | | | | | | | |
| | | MLD Query | | | | | MLD Query | |
| | |<--------------+ | | | |<--------------+ |
| | | | | | | | | |
| | | Join(G) | | | | | Join(G) | |
| | +-------------->| | | | +-------------->| |
| | | Aggregated Join(G) | | | Aggregated Join(G)
skipping to change at page 8, line 12 skipping to change at page 8, line 12
multicast, which is handled by an IGMP proxy function at the MAG in multicast, which is handled by an IGMP proxy function at the MAG in
an analogous way. an analogous way.
Following these deployment steps, multicast management transparently Following these deployment steps, multicast management transparently
inter-operates with PMIPv6. It is worth noting that MNs - while inter-operates with PMIPv6. It is worth noting that MNs - while
being attached to the same MAG, but associated with different LMAs - being attached to the same MAG, but associated with different LMAs -
can subscribe to the same multicast group. Thereby data could be can subscribe to the same multicast group. Thereby data could be
distributed redundantly in the network and duplicate traffic could distributed redundantly in the network and duplicate traffic could
arrive at a MAG. Additionally in a point-to-point wireless link arrive at a MAG. Additionally in a point-to-point wireless link
model, a MAG might be forced to transmit the same data over one model, a MAG might be forced to transmit the same data over one
wireless domain to different MNs. However, multicast traffic to one wireless domain to different MNs. However, multicast traffic
MN will always remain unique, i.e., the mobile multicast distribution arriving at one interface of the MN will always remain unique, i.e.,
system will never cause duplicate packets arriving at an MN (see the mobile multicast distribution system will never cause duplicate
Appendix C for further considerations). packets arriving at an MN (see Appendix C for further
considerations).
4. Deployment Details 4. Deployment Details
Multicast activation in a PMIPv6 domain requires to deploy general Multicast activation in a PMIPv6 domain requires to deploy general
multicast functions at PMIPv6 routers and to define their interaction multicast functions at PMIPv6 routers and to define their interaction
with the PMIPv6 protocol in the following way: with the PMIPv6 protocol in the following way:
4.1. Operations of the Mobile Node 4.1. Operations of the Mobile Node
A Mobile Node willing to manage multicast traffic will join, maintain A Mobile Node willing to manage multicast traffic will join, maintain
skipping to change at page 8, line 48 skipping to change at page 8, line 49
Update List as maintained by PMIPv6 standard operations (cf., section Update List as maintained by PMIPv6 standard operations (cf., section
6.1 of [RFC5213]). As links connecting MNs and MAGs change under 6.1 of [RFC5213]). As links connecting MNs and MAGs change under
mobility, MLD proxies at MAGs MUST be able to dynamically add and mobility, MLD proxies at MAGs MUST be able to dynamically add and
remove downstream interfaces in its configuration. remove downstream interfaces in its configuration.
On the reception of MLD reports from an MN, the MAG MUST identify the On the reception of MLD reports from an MN, the MAG MUST identify the
corresponding proxy instance from the incoming interface and perform corresponding proxy instance from the incoming interface and perform
regular MLD proxy operations: it will insert/update/remove multicast regular MLD proxy operations: it will insert/update/remove multicast
forwarding state on the incoming interface, and will merge state forwarding state on the incoming interface, and will merge state
updates into the MLD proxy membership database. It will then send an updates into the MLD proxy membership database. It will then send an
aggregated Report to the upstream tunnel to the LMA when the aggregated Report via the upstream tunnel to the LMA when the
membership database (cf., section 4.1 of [RFC4605]) changes. membership database (cf., section 4.1 of [RFC4605]) changes.
Conversely, on the reception of MLD Queries, the MAG proxy instance Conversely, on the reception of MLD Queries, the MAG proxy instance
will answer the Queries on behalf of all active downstream receivers will answer the Queries on behalf of all active downstream receivers
maintained in its membership database. Queries sent by the LMA do maintained in its membership database. Queries sent by the LMA do
not force the MAG to trigger corresponding messages immediately not force the MAG to trigger corresponding messages immediately
towards MNs. Multicast traffic arriving at the MAG on an upstream towards MNs. Multicast traffic arriving at the MAG on an upstream
interface will be forwarded according to the group/source-specific interface will be forwarded according to the group/source-specific
forwarding states as acquired for each downstream interface within forwarding states as acquired for each downstream interface within
the MLD proxy instance. At this stage, it is important to note that the MLD proxy instance. At this stage, it is important to note that
IGMP/MLD proxy implementations capable of multiple instances are IGMP/MLD proxy implementations capable of multiple instances are
skipping to change at page 11, line 33 skipping to change at page 11, line 33
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.
MLD/IGMP signaling between MNs and the MAG is on point-to-point links MLD/IGMP signaling between MNs and the MAG is on point-to-point links
(identical to unicast). Aggregated MLD/IGMP signaling between the (identical to unicast). Aggregated MLD/IGMP signaling between the
MAG proxy instance and the LMA remains link-local between the routers MAG proxy instance and the LMA remains link-local between the routers
and independent of any individual MN. So the MAG-proxy and the LMA and independent of any individual MN. So the MAG-proxy and the LMA
SHOULD not use GRE key identifiers, but plain GRE encapsulation to SHOULD not use GRE key identifiers, but plain GRE encapsulation to
exchange MLD queries and reports. Similarly, multicast traffic sent exchange MLD queries and reports. Similarly, multicast traffic sent
from an LMA to MAGs proceeds as router-to-router forwarding according from an LMA to MAGs proceeds as router-to-router forwarding according
to the MFIB of the LMA and independent of MN's unicast addresses, to the multicast forwarding information base (MFIB) of the LMA and
while the MAG proxy instance distributes multicast data down the independent of MN's unicast addresses, while the MAG proxy instance
point-to-point links (interfaces) according to its MFIB, independent distributes multicast data down the point-to-point links (interfaces)
of MN's IP addresses. according to its own MFIB, independent of MN's IP addresses.
It remains an open issue how communication proceeds in a multi- It remains an open issue how communication proceeds in a multi-
operator scenario, i.e., from which network the LMA pulls multicast operator scenario, i.e., from which network the LMA pulls multicast
traffic from. This could be any mobility Operator itself, or a third traffic. This could be any mobility Operator itself, or a third
party. However, this backbone routing in general is out of scope of party. However, this backbone routing in general is out of scope of
the document, and most likely a matter of contracts. the document, and most likely a matter of contracts.
4.5. Multihoming Support 4.5. Multihoming Support
An MN can connect to a PMIPv6 domain through multiple interfaces and An MN can connect to a PMIPv6 domain through multiple interfaces and
experience transparent unicast handovers at all interfaces (cf., experience transparent unicast handovers at all interfaces (cf.,
section 5.4 of [RFC5213]). In such simultaneous access scenario, it section 5.4 of [RFC5213]). In such simultaneous access scenario, it
can autonomously assign multicast channel subscriptions to individual can autonomously assign multicast channel subscriptions to individual
interfaces (see [RFC5757] for additional details). While doing so, interfaces (see [RFC5757] for additional details). While doing so,
skipping to change at page 14, line 26 skipping to change at page 14, line 26
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
This memo follows initial requirements work presented in This memo follows initial requirements work presented in
draft-deng-multimob-pmip6-requirement, and is the outcome of draft-deng-multimob-pmip6-requirement, and is the outcome of
extensive previous discussions and a follow-up of several initial extensive previous discussions and a follow-up of several initial
drafts on the subject. The authors would like to thank (in drafts on the subject. The authors would like to thank (in
alphabetical order) Jari Arkko, Luis Contreras, Greg Daley, Gorry alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley, Gorry
Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Guang Lu, Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Guang Lu,
Sebastian Meiling, Liu Hui, Akbar Rahman, Imed Romdhani, Behcet Sebastian Meiling, Liu Hui, Akbar Rahman, Imed Romdhani, Behcet
Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for
advice, help and reviews of the document. Funding by the German advice, help and reviews of the document. Funding by the German
Federal Ministry of Education and Research within the G-LAB Federal Ministry of Education and Research within the G-LAB
Initiative is gratefully acknowledged. Initiative is gratefully acknowledged.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 18, line 47 skipping to change at page 18, line 47
smaller problems in scalability than the stream replication at LMAs smaller problems in scalability than the stream replication at LMAs
(avalanche problem). For scenario A it should be also noted that the (avalanche problem). For scenario A it should be also noted that the
high stream replication requirements at LMAs in setting 1 can be high stream replication requirements at LMAs in setting 1 can be
attenuated by deploying additional LMAs in a PMIP domain, while attenuated by deploying additional LMAs in a PMIP domain, while
scenario B does not allow for distributing the LMA-M, as no handover scenario B does not allow for distributing the LMA-M, as no handover
management is available at LMA-M. management is available at LMA-M.
Appendix D. Change Log Appendix D. Change Log
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-04.
1. Clarifications and editorial improvements in response to WG
feedback.
The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-03. draft-ietf-multimob-pmipv6-base-solution-03.
1. Clarifications and editorial improvements in response to WG 1. Clarifications and editorial improvements in response to WG
feedback. feedback.
2. Added pointers and explanations to Explicit Tracking and GRE 2. Added pointers and explanations to Explicit Tracking and GRE
tunneling in the IPv4 scenario (RFC 5845). tunneling in the IPv4 scenario (RFC 5845).
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-02. draft-ietf-multimob-pmipv6-base-solution-02.
 End of changes. 14 change blocks. 
28 lines changed or deleted 35 lines changed or added

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