draft-ietf-multimob-pmipv6-source-07.txt   draft-ietf-multimob-pmipv6-source-08.txt 
MULTIMOB Group T. Schmidt, Ed. MULTIMOB Group T. Schmidt, Ed.
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: Experimental S. Gao Intended status: Experimental S. Gao
Expires: July 9, 2014 H. Zhang Expires: September 4, 2014 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
January 5, 2014 March 3, 2014
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-07 draft-ietf-multimob-pmipv6-source-08
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 a base solution and an experimental protocol This document describes a base solution and an experimental protocol
to support of mobile multicast senders in Proxy Mobile IPv6 domains to support mobile multicast senders in Proxy Mobile IPv6 domains for
for all three scenarios. Protocol optimizations for synchronizing all three scenarios. Protocol optimizations for synchronizing PMIPv6
PMIPv6 with PIM, as well as a peering function for MLD Proxies are with PIM, as well as a peering function for MLD Proxies are defined.
defined. Mobile sources always remain agnostic of multicast mobility Mobile sources always remain agnostic of multicast mobility
operations. 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
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 9, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Efficiency of the Distribution System . . . . . . . . 10 3.2.5. Efficiency of the Distribution System . . . . . . . . 10
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 11 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 11
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 13 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 13
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13 4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13
4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 14 4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 14
4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 15 4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 15
4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 15 4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 15
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17
5. MLD Proxy Peering Function for Optimized Source Mobility in 5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Operations in Support of Multicast Senders . . . . . . . 19 5.3. Operations in Support of Multicast Senders . . . . . . . 19
skipping to change at page 3, line 44 skipping to change at page 3, line 44
extensions in the sense that it follows the common PMIPv6 traffic extensions in the sense that it follows the common PMIPv6 traffic
model and neither requires new protocol operations nor additional model and neither requires new protocol operations nor additional
infrastructure entities. Standard software functions need to be infrastructure entities. Standard software functions need to be
activated on PMIPv6 entities, only, at the price of possibly non- activated on PMIPv6 entities, only, at the price of possibly non-
optimal multicast routing. optimal multicast routing.
Alternate solutions leverage performance optimization by providing Alternate solutions leverage performance optimization by providing
multicast routing at the access gateways directly multicast routing at the access gateways directly
[I-D.ietf-multimob-fmipv6-pfmipv6-multicast], or by selective route [I-D.ietf-multimob-fmipv6-pfmipv6-multicast], or by selective route
optimization schemes [RFC7028]. Such approaches (partially) follow optimization schemes [RFC7028]. Such approaches (partially) follow
the business model of providing multicast data services in parallel the model of providing multicast data services in parallel to PMIPv6
to PMIPv6 unicast routing [I-D.ietf-multimob-handover-optimization]. unicast routing [I-D.ietf-multimob-handover-optimization].
Multicast listener support satisfies the needs of receptive use cases Multicast listener support satisfies the needs of receptive use cases
such as IPTV or server-centric gaming on mobiles. However, current such as IPTV or server-centric gaming on mobiles. However, current
trends in the Internet develop towards user-centric, highly trends in the Internet develop towards user-centric, highly
interactive group applications like user generated streaming, interactive group applications like user generated streaming,
conferencing, collective mobile sensing, etc. Many of these popular conferencing, collective mobile sensing, etc. Many of these popular
applications create group content at end systems and can largely applications create group content at end systems and can largely
profit from a direct data transmission to a multicast-enabled profit from a direct data transmission to a multicast-enabled
network. network.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
scenario [RFC6224], for direct traffic distribution within an ISP's scenario [RFC6224], for direct traffic distribution within an ISP's
access network, as well as for selective route optimization schemes. access network, as well as for selective route optimization schemes.
The contribution of this work reflects the source mobility problem as The contribution of this work reflects the source mobility problem as
discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic
of multicast mobility operations. of multicast mobility operations.
2. Terminology 2. Terminology
This document uses the terminology as defined for the mobility This document uses the terminology as defined for the mobility
protocols [RFC6275], [RFC5213] and [RFC5844], as well as the protocols [RFC6275], [RFC5213] and [RFC5844], as well as the
multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. multicast routing [RFC4601] and edge related protocols [RFC3376],
[RFC3810] and [RFC4605].
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. It displays the general setting domains is illustrated in Figure 1. It displays the general setting
for source mobility - Mobile Nodes (MNs) with Home Network Prefixes for source mobility - Mobile Nodes (MNs) with Home Network Prefixes
(HNPs) that receive services via tunnels, which are spanned between a (HNPs) that receive services via tunnels, which are spanned between a
Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address
skipping to change at page 13, line 45 skipping to change at page 13, line 45
position PIM Rendezvous Points (RPs) in the core of the PMIPv6 position PIM Rendezvous Points (RPs) in the core of the PMIPv6
network domain. However, regular IP routing tables need not be network domain. However, regular IP routing tables need not be
present in a PMIPv6 deployment, and additional effort is required to present in a PMIPv6 deployment, and additional effort is required to
establish reverse path forwarding rules as required by PIM-SM. establish reverse path forwarding rules as required by PIM-SM.
4.3.1. Routing Information Base for PIM-SM 4.3.1. Routing Information Base for PIM-SM
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 (specific phase)
deployment. of its deployment.
The following information is needed for all three phases of PIM as For all three phases in the operation of PIM (see [RFC4601]), the
defined in [RFC4601]. following information is needed.
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 MUST remain unaffected by node mobility. among PIM routers and MUST remain unaffected by node mobility.
The setup of these general routes is expected to follow the The setup of these general routes is expected to follow the
topology of the operator network and is beyond the scope of this topology of the operator network and is beyond the scope of this
document. 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.
skipping to change at page 14, line 22 skipping to change at page 14, line 22
o Local routes to the Home Network Prefixes (HNPs) of all MNs o Local routes to the Home Network Prefixes (HNPs) of all MNs
associated with their corresponding point-to-point attachments associated with their corresponding point-to-point attachments
that MUST be included in the local MRIB. that MUST be included in the local 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 (RP Tree)
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
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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 trees for mobile configured to not initiated (S,G) shortest path trees 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 (Register-Stop)
After receiving source register packets, a PIM RP eventually will After receiving source register packets, a PIM RP eventually will
initiate 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 the HNP of the as all intermediate routers, require route entries for the HNP of the
MN that - unless the RP coincides with the MAG of S - point towards MN that - unless the RP coincides with the MAG of S - point towards
the 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, down the LMA-MAG tunnel to the from the RP via the (stable) LMA, down the LMA-MAG tunnel to the
mobile source. This tree can be of lower routing efficiency than the mobile source. This tree can be of lower routing efficiency than the
skipping to change at page 15, line 35 skipping to change at page 15, line 35
the RP had previously joined the shortest path tree towards the the RP had previously joined the shortest path tree towards the
source via the LMA, it will see an RPF change when data arrives at a source via the LMA, it will see an RPF change when data arrives at a
new interface. Implementation-dependent, this can trigger an update new interface. Implementation-dependent, this can trigger an update
of the PIM MRIB and trigger a new PIM Join message that will install of the PIM MRIB and trigger a new PIM Join message that will install
the multicast forwarding state missing at the new MAG. Otherwise, the multicast forwarding state missing at the new MAG. Otherwise,
the tree is periodically updated by Joins transmitted towards the new the tree is periodically updated by Joins transmitted towards the new
MAG on a path via the LMA. In proceeding this way, a quick recovery 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 of PIM transition from phase one to two will be performed per
handover. handover.
4.3.4. Operations of PIM in Phase Three 4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree)
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 initiate a source-specific Join for receivers eventually will initiate 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 range 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, and the the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the
serving MAG to the mobile source. This tree is of higher routing serving MAG to the mobile source. This tree is of higher routing
efficiency than that established in the previous phase two, but need efficiency than that established in the previous phase two, but need
not outperform the PIM source register tunnel established in phase not outperform the PIM source register tunnel established in phase
skipping to change at page 21, line 20 skipping to change at page 21, line 20
This document makes no request to IANA.. This document makes no request to IANA..
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
This document defines multicast sender mobility based on PMIPv6 and This document defines multicast sender mobility based on PMIPv6 and
common multicast routing protocols. Consequently, threats identified common multicast routing protocols. Consequently, threats identified
as security concerns of [RFC2710] [RFC3810], [RFC4605], [RFC5213], as security concerns of [RFC2236], [RFC2710], , [RFC3810], [RFC4605],
and [RFC5844] are inherited by this document. [RFC5213], and [RFC5844] are inherited by this document.
In addition, particular attention should be paid to implications of In addition, particular attention should be paid to implications of
combining multicast and mobility management at network entities. As combining multicast and mobility management at network entities. As
this specification allows mobile nodes to initiate the creation of this specification allows mobile nodes to initiate the creation of
multicast forwarding states at MAGs and LMAs while changing multicast forwarding states at MAGs and LMAs while changing
attachments, threats of resource exhaustion at PMIP routers and attachments, threats of resource exhaustion at PMIP routers and
access networks arrive from rapid state changes, as well as from high access networks arrive from rapid state changes, as well as from high
volume data streams routed into access networks of limited volume data streams routed into access networks of limited
capacities. In cases of PIM-SM deployment, handover operations of capacities. In cases of PIM-SM deployment, handover operations of
the MNs include re-registering sources at the Rendezvous Points at the MNs include re-registering sources at the Rendezvous Points at
skipping to change at page 22, line 7 skipping to change at page 22, line 7
upstream interfaces are prevented by filters on local sources. Such upstream interfaces are prevented by filters on local sources. Such
filtering can fail, whenever prefix configurations for downstream filtering can fail, whenever prefix configurations for downstream
interfaces at a proxy are incorrect or inconsistent. Consequently, interfaces at a proxy are incorrect or inconsistent. Consequently,
implementations of peering-enabled proxies SHOULD take particular implementations of peering-enabled proxies SHOULD take particular
care on maintaining (varying) IP configurations at the downstream in care on maintaining (varying) IP configurations at the downstream in
a reliable and timely manner (see [RFC6224] for requirements on a reliable and timely manner (see [RFC6224] for requirements on
PMIPv6-compliant implementations of MLD proxies). PMIPv6-compliant implementations of MLD proxies).
8. Acknowledgements 8. Acknowledgements
The authors would like to thank (in alphabetical order) Luis M. The authors would like to thank (in alphabetical order) David Black,
Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Luis M. Contreras, Muhamma Omer Farooq, Bohao Feng, Sri Gundavelli,
Jouni Korhonen, He-Wu Li, Cong Liu, Akbar Rahman, Behcet Sarikaya, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li, Cong Liu, Akbar
Stig Venaas, Li-Li Wang, Sebastian Woelke, Qian Wu, Zhi-Wei Yan for Rahman, Behcet Sarikaya, Stig Venaas, Li-Li Wang, Sebastian Woelke,
advice, help and reviews of the document. Funding by the German Qian Wu, Zhi-Wei Yan for advice, help and reviews of the document.
Federal Ministry of Education and Research within the G-LAB Funding by the German Federal Ministry of Education and Research
Initiative (projects HAMcast, Mindstone and SAFEST) 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, October Listener Discovery (MLD) for IPv6", RFC 2710, October
skipping to change at page 23, line 14 skipping to change at page 23, line 14
[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-fmipv6-pfmipv6-multicast] [I-D.ietf-multimob-fmipv6-pfmipv6-multicast]
Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and
D. Liu, "Multicast Listener Extensions for MIPv6 and D. Liu, "Multicast Listener Extensions for MIPv6 and
PMIPv6 Fast Handovers", draft-ietf-multimob- PMIPv6 Fast Handovers", draft-ietf-multimob-
fmipv6-pfmipv6-multicast-01 (work in progress), February fmipv6-pfmipv6-multicast-03 (work in progress), February
2013. 2014.
[I-D.ietf-multimob-handover-optimization] [I-D.ietf-multimob-handover-optimization]
Contreras, L., Bernardos, C., and I. Soto, "PMIPv6 Contreras, L., Bernardos, C., and I. Soto, "PMIPv6
multicast handover optimization by the Subscription multicast handover optimization by the Subscription
Information Acquisition through the LMA (SIAL)", draft- Information Acquisition through the LMA (SIAL)", draft-
ietf-multimob-handover-optimization-06 (work in progress), ietf-multimob-handover-optimization-07 (work in progress),
November 2013. December 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.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
 End of changes. 17 change blocks. 
35 lines changed or deleted 36 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/