| TOC |
|
Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latencies. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, are comprised of delay-sensitive real-time traffic and could strongly benefit from fast handover execution. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
2.
Terminology
3.
Protocol Overview
3.1.
Multicast Context Transfer between Access Routers
3.2.
Protocol Operations Specific to FMIPv6
3.3.
Protocol Operations Specific to PFMIPv6
4.
Protocol Details
4.1.
Generals
4.2.
Protocol Operations Specific to FMIPv6
4.3.
Protocol Operations Specific to PFMIPv6
4.3.1.
IPv4 Support Considerations
5.
Message Formats
5.1.
Multicast Indicator for Proxy Router Advertisement (PrRtAdv)
5.2.
Extensions to Existing Mobility Header Messages
5.3.
New Multicast Mobility Option
5.3.1.
Number of Addresses
5.4.
New Multicast Acknowledgement Option
5.5.
MLD (IGMP) Compatibility Aspects
6.
Security Considerations
7.
IANA Considerations
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
| TOC |
Mobile IPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) defines a network layer mobility protocol involving mobile nodes participation, while Proxy Mobile IPv6 [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) provides a mechanism without requiring mobility protocol operations at a Mobile Node (MN). Both protocols introduce traffic disruptions on handovers that may be intolerable in many application scenarios. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] (Koodli, R., “Mobile IPv6 Fast Handovers,” July 2009.), and Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) [I‑D.ietf‑mipshop‑pfmipv6] (Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, “Fast Handovers for Proxy Mobile IPv6,” April 2010.) improve these handover delays for unicast communication to the order of the maximum delay needed for link switching and signaling between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6‑Analysis] (Schmidt, TC. and M. Waehlisch, “Predictive versus Reactive - Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility,” November 2005.).
No dedicated treatment of seamless multicast data reception has been proposed by any of the above protocols. MIPv6 only roughly defines multicast for Mobile Nodes using a remote subscription approach or a home subscription through bi-directional tunneling via the Home Agent (HA). Multicast forwarding services have not been specified at all in [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.), but are subject to further specifications. It is assumed throughout this document that mechanisms and protocol operations are in place to transport multicast traffic to ARs. Symbolically, these operations are referred to as 'JOIN/LEAVE' of an AR, while the explicit techniques to manage multicast transmission are beyond the scope of this document.
Mobile multicast protocols need to serve applications like IPTV with voluminous content streams to be distributed to potentially large numbers of receivers, and therefore should preserve the multicast nature of packet distribution and approximate optimal routing [RFC5757] (Schmidt, T., Waehlisch, M., and G. Fairhurst, “Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey,” February 2010.). It is undesirable to rely on home tunneling for optimizing multicast. Native multicast forwarding requires forwarding states, which will not be transferred between access routers by the unicast fast handover protocols. Thus multicast traffic will not experience expedited handover performance, but an MN can continuously perform remote subscriptions in the visited networks.
This document specifies extension of FMIPv6 and PFMIPv6 for including multicast traffic management in fast handover operations. The solution common to both underlying protocols defines the per group transfer of multicast contexts between ARs or MAGs. The protocol defines corresponding message extensions necessary for carrying group context information independent of the particular handover protocol in use. ARs or MAGs are then enabled to treat multicast traffic in correspondence to fast unicast handovers and with analogous performance. No protocol changes are introduced that prevent a multicast unaware node from performing fast handovers with multicast aware ARs or MAGs.
This specification is applicable when a mobile node has joined and maintains one or several multicast groups prior to undergoing a fast handover. It does not pose any requirements on multicast routing protocols in use, nor are the ARs or MAGs assumed to be multicast routers. It assumes network conditions, though, that allow native multicast reception in both, the previous and new access network. Methods to bridge regions without native multicast connectivity are beyond the scope of this document.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.). The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.
This document uses the terminology of [RFC5568] (Koodli, R., “Mobile IPv6 Fast Handovers,” July 2009.), [I‑D.ietf‑mipshop‑pfmipv6] (Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, “Fast Handovers for Proxy Mobile IPv6,” April 2010.), [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), and [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.). In addition, the following terms are introduced:
| TOC |
The reference scenario for multicast fast handover is illustrated in Figure 1 (Reference Network for Fast Handover).
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
| Figure 1: Reference Network for Fast Handover |
| TOC |
In a fast handover scenario (cf. Figure 1 (Reference Network for Fast Handover)), ARs/MAGs establish a mutual binding and provide the capability to exchange context information concerning the MN. This context transfer will be triggered by detecting MN's forthcoming move to a new AR and assist the MN to immediately resume communication on the new subnet link using its previous IP address. In contrast to unicast, multicast stream reception does not primarily depend on address and binding cache management, but requires distribution trees to adapt such that traffic follows the MN. This process may be significantly slower than fast handover management [RFC5757] (Schmidt, T., Waehlisch, M., and G. Fairhurst, “Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey,” February 2010.). Multicast listeners at handover may take twofold advantage of including the multicast groups under subscription in context transfer. First, the NAR can proactively join the desired groups as soon as it gains knowledge thereof. Second, multicast streams may be included in traffic forwarding via the tunnel established from PAR to NAR.
There are two modes of operation in FMIPv6 and in PFMIPv6. The predictive mode allows for AR-binding and context transfer prior to MN's handover, while in the reactive mode, these steps are executed after the MN's re-attachment to NAR has been detected. Details of the signaling schemes differ between FMIPv6 and PFMIPv6 and are outlined in Section 3.2 (Protocol Operations Specific to FMIPv6) and Section 3.3 (Protocol Operations Specific to PFMIPv6).
In a predictive fast handover, the access router (e.g., PAR in Figure 1 (Reference Network for Fast Handover)) learns about the impending movement of the MN and simultaneously about the multicast group context as specified in Section 3.2 (Protocol Operations Specific to FMIPv6) and Section 3.3 (Protocol Operations Specific to PFMIPv6). Thereafter, PAR will initiate an AR-binding and context transfer by transmitting a HI message to NAR. HI is extended by multicast group states carried in mobility header options as defined in Section 5.3 (New Multicast Mobility Option). On reception of the HI message, NAR returns a multicast acknowledgement in its HACK answer that per group indicates its ability to support the requested group, as well as its willingness to receive multicast traffic forwarded from PAR (see Section 5.4 (New Multicast Acknowledgement Option)). There are several reasons to waive forwarding, e.g., the group may already be under native subscription or capacity constraints at the NAR may hinder decapsulation of additional streams. For the groups requested, PAR will add the tunnel interface to its multicast forwarding database, so that multicast streams are forwarded in parallel to unicast traffic. NAR, taking the role of an MLD proxy [RFC4605] (Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” August 2006.) with the upstream tunnel interface to PAR, will submit an MLD report to request for the desired groups, but will terminate multicast forwarding [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) from PAR, as soon as group traffic natively arrives. In addition, NAR immediately joins all groups that are not already under subscription using its loopback interface, and starts multicast forwarding after the MN has arrived.
In a reactive fast handover, PAR will learn about the movement of the MN, after the latter has re-associated with the new access network. Also from the new link, it will be informed about the multicast context of the MN. As group membership information are present at the new access network prior to context transfer, MLD join signaling can proceed in parallel to HI/HACK exchange. Depending on the specific network topology, multicast traffic for some groups may natively arrive before it is forwarded from PAR. However, PAR-NAR forwarding SHOULD be procured for groups in far reach.
In both modes of operation, it is the responsibility of the PAR (PMAG) to properly consider the departure of the MN for the local group management. Depending on the multicast state management, link type and MLD parameters deployed (cf., [RFC5757] (Schmidt, T., Waehlisch, M., and G. Fairhurst, “Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey,” February 2010.)), it SHOULD take appropriate actions to adjust multicast service to requirements of the remaining nodes.
In this way, the MN will be able to participate in multicast group communication with handover experiences comparable to unicast performance, while network resources are preserved whenever possible.
| TOC |
ARs that provide multicast support in FMIPv6 will advertise this general service by setting an indicator bit (M-bit) in its PrRtAdv message as defined in Section 5.1 (Multicast Indicator for Proxy Router Advertisement (PrRtAdv)). Additional details about the multicast service support, e.g., flavors and groups, will be exchanged within HI/HACK dialogs later at handovers.
An MN operating FMIPv6 will actively initiate the handover management by submitting a fast binding update (FBU). The MN, which is aware of the multicast groups it wishes to maintain, will attach mobility options containing its group states (see Section 5.3 (New Multicast Mobility Option)) to the FBU, and thereby inform ARs about its multicast context. ARs will use these multicast context options for inter-AR context transfer.
In predictive mode, FBU is issued on the previous link and received by PAR as displayed in Figure 2 (Predictive Multicast Handover for FMIPv6). PAR will extract the multicast context options and append them to its HI message. From the HACK message, PAR will redistribute the multicast acknowledgement by adding the corresponding mobility options to its FBACK message. From receiving FBACK, the MN will learn about a per group multicast support in the new access network. If some groups or a multicast flavour are not supported, it may decide on taking actions to compensate the missing service. Note that the proactive multicast context transfer may proceed successfully, even if the MN misses the FBACK message on the previous link.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
| | |
|---------FBU-------->|----------HI--------->|
| (Multicast MobOpt) | (Multicast MobOpt) |
| | |
| |<--------HAck---------|
| | (Multicast AckOpt) |
| | Join to
| | Multicast
| | Groups
| | |
| <-----FBack---|--FBack------> |
| (Multicast AckOpt) | (Multicast AckOpt) |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
| Figure 2: Predictive Multicast Handover for FMIPv6 |
The call flow for reactive mode is visualized in Figure 3 (Reactive Multicast Handover for FMIPv6). After attaching to the new access link and performing an unsolicited neighbor advertisement (UNA), the MN issues an FBU which NAR forwards to PAR without processing. At this time, MN is able to re-join all desired multicast groups without relying on AR assistance. Nevertheless, multicast context options are exchanged in the HI/HACK dialog to facilitate intermediate forwarding of requested streams. Note that group traffic may already arrive from MN's subscription at the time NAR receives the HI message. Such streams may be transparently excluded from forwarding by setting an appropriate multicast acknowledge option. In any case, NAR MUST ensure that not more than one stream of the same group is forwarded to the MN.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| (Multicast MobOpt) |<-------FBU----------)|
| | |
Join to | |
Multicast | |
Groups | |
| |----------HI--------->|
| | (Multicast MobOpt) |
| |<-------HAck----------|
| | (Multicast AckOpt) |
| | |
| |(HI/HAck if necessary)|
| | |
| forward |
| packets(including FBack)=====>|
| | |
|<=================================== deliver packets
| |
| Figure 3: Reactive Multicast Handover for FMIPv6 |
| TOC |
In a proxy mobile IPv6 environment, the MN remains agnostic of network layer changes, and fast handover operations are pursued by the access routers or MAGs. The handover initiation, or the re-association respectively is managed by the access networks. Consequently, access routers need to be aware of multicast membership states at the mobile node. There are two ways to obtain record of MN's multicast membership. First, MAGs may perform an explicit tracking (cf., [RFC4605] (Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” August 2006.), [I‑D.ietf‑multimob‑pmipv6‑base‑solution] (Schmidt, T., Waehlisch, M., and S. Krishnan, “Base Deployment for Multicast Listener Support in PMIPv6 Domains,” February 2010.)) or extract membership status from forwarding states at node-specific point-to-point links. Second, routers may perform general queries. Both methods are equally applicable, which leaves a final choice to the implementation. In either case, the PAR will become knowledgeable about multicast group subscriptions of the MN.
In predictive mode, the PMAG (PAR) will learn about the upcoming movement of the mobile node. Without explicit tracking, it will immediately submit a general MLD query and learn about the multicast groups under subscription. As displayed in Figure 4 (Predictive Multicast Handover for PFMIPv6), it will initiate binding and context transfer with the NMAG (NAR) by issuing a HI message that is augmented by multicast contexts in the mobility options defined in Section 5.3 (New Multicast Mobility Option)). NAR will extract multicast context information and act as described in Section 3.1 (Multicast Context Transfer between Access Routers).
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|-(MN ID,-->| | | |
| New AP ID)| | | |
| | HO Initiate | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HAck-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | forward |
| | | packets =======>|
disconnect | | | |
| | | | |
connect | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | | (substitute for UNA) |
| | | | |
|<======================================== deliver packets
| | | | |
| Figure 4: Predictive Multicast Handover for PFMIPv6 |
In reactive mode, the NMAG (NAR) will learn about MN's attachment to the N-AN and establish connectivity by means of PMIPv6 protocol operations. However, it will have no knowledge about multicast states at the MN. Triggered by MN's attachment, the NMAG will inquire on group memberships by submitting a general MLD query and thereafter join the requested groups. In the case of a reactive handover, the binding is initiated by NMAG, and the HI/HACK message semantic is inverted (see [I‑D.ietf‑mipshop‑pfmipv6] (Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, “Fast Handovers for Proxy Mobile IPv6,” April 2010.)). For multicast context transfer, the NMAG attaches those group identifiers in multicast mobility options which it requests for forwarding. Using the identical syntax in its option headers as defined in Section 5.4 (New Multicast Acknowledgement Option), PMAG acknowledges the group forwarding request in its HACK answer. The corresponding call flow is displayed in Figure 5 (Reactive Multicast Handover for PFMIPv6).
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
disconnect | | | |
| | | | |
connect | | | |
| | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | |(substitute for UNA & FBU)|
| | | | |
| | | | MLD Query
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | |
| | | |<------HI----|
| | | |(Multicast MobOpt)
| | | | |
| | | |---HAck----->|
| | | |(Multicast AckOpt)
| | | | |
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | forward |
| | | packets =======>|
| | | | |
|<======================================== deliver packets
| | | | |
| Figure 5: Reactive Multicast Handover for PFMIPv6 |
| TOC |
| TOC |
:::TODO:
| TOC |
:::TODO:
| TOC |
:::TODO:
| TOC |
:::TODO:
| TOC |
| TOC |
An FMIPv6 AR will indicate its multicast support by activating an M-bit in its Proxy Router Advertisements (PrRtAdv). The message extension is of the following form.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |M| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
| Figure 6: Multicast Indicator Bit for Proxy Router Advertisement (PrRtAdv) Message |
| TOC |
Multicast listener context of an MN is transferred in fast handover operations from PAR/PMAG to NAR/NMAG within a new Multicast Mobility Option, and acknowledged by a corresponding Acknowledgement Option. Depending on the specific handover scenario and protocol in use, the corresponding option is included within the mobility option list of HI/HAck only (PFMIPv6), or of FBU/FBAck/HI/HAck (FMIPv6).
| TOC |
The Multicast Mobility Option contains the current listener state record of the MN as obtained from the MLD Report message, and has the format displayed in Figure 7 (Mobility Header Multicast Option).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD (IGMP) Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 7: Mobility Header Multicast Option |
Type: XX
Length: 8-bit unsigned integer. The size of this option in 8 octets including the Type, Option-Code, and Length fields.
- Option-Code:
- 1:
- IGMPv3 Payload Type
- 2:
- MLDv2 Payload Type
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
MLD (IGMP) Report Payload: this field is composed of the MLD (IGMP) Report message after stripping its ICMP header line. Corresponding message formats are defined for MLDv2 in [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.), and for IGMPv3 in [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.).
Figure 8 (MLDv2 Report Payload) shows the Report Payload for MLDv2, while the payload format for IGMPv3 is defined correspondingly (see Section 5.2. of [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) for the definition of Multicast Address Records).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 8: MLDv2 Report Payload |
| TOC |
| TOC |
The Multicast Acknowledgement Option reports on the status of context transfer and contains the list of state records that could not successfully be transferred to the next access network. It has the format displayed in Figure 9 (Mobility Header Multicast Acknowledgement Option).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD (IGMP) Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 9: Mobility Header Multicast Acknowledgement Option |
Type: XX
Length: 8-bit unsigned integer. The size of this option in 8 octets. The length is 1 when MLD (IGMP) Unsupported Report Payload field contains no Mcast Address Record.
Option-Code: 0
- Status:
- 1:
- Report Payload type unsupported
- 2:
- Requested group service unsupported
- 3:
- Requested group service administratively prohibited
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
MLD (IGMP) Unsupported Report Payload: this field is syntactically identical to the MLD (IGMP) Report Payload field described in Section 5.3 (New Multicast Mobility Option), but is only composed of those multicast address records that are not supported or prohibited in the new access network. This field MUST always contain the first header line (reserved field and Nr of Mcast Address Records), but MUST not contain any Mcast Address Record, if status code equals 1.
Note that group subscriptions to specific sources may be rejected at the destination network, and thus the composition of multicast address records may differ from initial requests within an MLD (IGMP) Report Payload option.
| TOC |
:::TODO:
| TOC |
:::TODO:
| TOC |
This document defines new Mobility Options that need Type assignment from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters ....
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3775] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [RFC5213] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
| [RFC5568] | Koodli, R., “Mobile IPv6 Fast Handovers,” RFC 5568, July 2009 (TXT). |
| [I-D.ietf-mipshop-pfmipv6] | Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, “Fast Handovers for Proxy Mobile IPv6,” draft-ietf-mipshop-pfmipv6-13 (work in progress), April 2010 (TXT). |
| [RFC1112] | Deering, S., “Host extensions for IP multicasting,” STD 5, RFC 1112, August 1989 (TXT). |
| [RFC4605] | Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” RFC 4605, August 2006 (TXT). |
| [RFC3810] | Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” RFC 3810, June 2004 (TXT). |
| [RFC3376] | Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” RFC 3376, October 2002 (TXT). |
| TOC |
| [RFC5757] | Schmidt, T., Waehlisch, M., and G. Fairhurst, “Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey,” RFC 5757, February 2010 (TXT). |
| [fmcast-mip6] | Suh, K., Kwon, D., Suh, Y., and Y. Park, “Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments,” draft-suh-mipshop-fmcast-mip6-00 (work in progress), July 2004 (TXT). |
| [FMIPv6-Analysis] | Schmidt, TC. and M. Waehlisch, “Predictive versus Reactive - Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility,” Telecommunication Systems Vol 33, No. 1-3, pp. 131-154, November 2005. |
| [I-D.ietf-multimob-pmipv6-base-solution] | Schmidt, T., Waehlisch, M., and S. Krishnan, “Base Deployment for Multicast Listener Support in PMIPv6 Domains,” draft-ietf-multimob-pmipv6-base-solution-00 (work in progress), February 2010 (TXT). |
| [PMIPv6v4] | Wakikawa, R. and S. Gundavelli, “IPv4 Support for Proxy Mobile IPv6,” draft-ietf-netlmm-pmip6-ipv4-support-04 (work in progress), July 2008 (TXT). |
| TOC |
| Thomas C. Schmidt | |
| HAW Hamburg | |
| Dept. Informatik | |
| Berliner Tor 7 | |
| Hamburg, D-20099 | |
| Germany | |
| Email: | Schmidt@informatik.haw-hamburg.de |
| Matthias Waehlisch | |
| link-lab | |
| Hoenower Str. 35 | |
| Berlin D-10318 | |
| Germany | |
| Email: | mw@link-lab.net |
| Rajeev Koodli | |
| Cisco Systems | |
| 30 International Place | |
| Xuanwu District, | |
| Tewksbury MA 01876 | |
| USA | |
| Email: | rkoodli@cisco.com |
| Godred Fairhurst | |
| University of Aberdeen | |
| School of Engineering | |
| Aberdeen AB24 3UE | |
| UK | |
| Email: | gorry@erg.abdn.ac.uk |