Internet DRAFT - draft-ietf-multimob-fmipv6-pfmipv6-multicast
draft-ietf-multimob-fmipv6-pfmipv6-multicast
MULTIMOB Group T. Schmidt, Ed.
Internet-Draft HAW Hamburg
Updates: 5568 (if approved) M. Waehlisch
Intended status: Experimental link-lab & FU Berlin
Expires: April 19, 2015 R. Koodli
Intel
G. Fairhurst
University of Aberdeen
Dapeng. Liu
China Mobile
October 16, 2014
Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers
draft-ietf-multimob-fmipv6-pfmipv6-multicast-10
Abstract
Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6
(PMIPv6) define mobility management procedures that support unicast
communication at reduced handover latency. 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, comprise
delay-sensitive real-time traffic and will benefit from fast handover
completion. 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 multicast support is provided first at the
control plane by a management of rapid context transfer between
access routers, second at the data plane by an optional fast traffic
forwarding that may include buffering. An FMIPv6 access router
indicates support for multicast using an updated Proxy Router
Advertisements message format.
This document updates RFC5568 "Mobile IPv6 Fast Handovers".
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Schmidt, et al. Expires April 19, 2015 [Page 1]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
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."
This Internet-Draft will expire on April 19, 2015.
Copyright Notice
Copyright (c) 2014 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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Cases and Deployment Scenarios . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Multicast Context Transfer between Access Routers . . . . 6
3.2. Protocol Operations Specific to FMIPv6 . . . . . . . . . 8
3.3. Protocol Operations Specific to PFMIPv6 . . . . . . . . . 11
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Protocol Operations Specific to FMIPv6 . . . . . . . . . 15
4.1.1. Operations of the Mobile Node . . . . . . . . . . . . 15
4.1.2. Operations of the Previous Access Router . . . . . . 15
4.1.3. Operations of the New Access Router . . . . . . . . . 16
4.1.4. Buffering Considerations . . . . . . . . . . . . . . 17
4.2. Protocol Operations Specific to PFMIPv6 . . . . . . . . . 17
4.2.1. Operations of the Mobile Node . . . . . . . . . . . . 17
4.2.2. Operations of the Previous MAG . . . . . . . . . . . 17
4.2.3. Operations of the New MAG . . . . . . . . . . . . . . 19
4.2.4. IPv4 Support Considerations . . . . . . . . . . . . . 20
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Multicast Indicator for Proxy Router Advertisement
(PrRtAdv) . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Extensions to Existing Mobility Header Messages . . . . . 21
5.3. New Multicast Mobility Option . . . . . . . . . . . . . . 21
5.4. New Multicast Acknowledgement Option . . . . . . . . . . 23
Schmidt, et al. Expires April 19, 2015 [Page 2]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
5.5. Length Considerations: Number of Records and Addresses . 25
5.6. MLD and IGMP Compatibility Requirements . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Considerations for Mobile Multicast Sources . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
Mobile IPv6 [RFC6275] defines a network layer mobility protocol
involving participation by mobile nodes, while Proxy Mobile IPv6
[RFC5213] 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 real-time
application scenarios such as gaming or conferencing. Mobile IPv6
Fast Handovers (FMIPv6) [RFC5568], and Fast Handovers for Proxy
Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of these
handover delays for unicast communication to the order of the maximum
of the delays needed for link switching and signaling between Access
Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis].
No dedicated treatment of seamless IP multicast [RFC1112] data
service 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 in [RFC5213], but are subject to separate
specifications [RFC6224], [RFC7287]. It is assumed throughout this
document that mechanisms and protocol operations are in place to
transport multicast traffic to ARs. 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 support applications such as IPTV
with high-volume content streams and allow distribution to
potentially large numbers of receivers. They should thus preserve
the multicast nature of packet distribution and approximate optimal
routing [RFC5757]. It is undesirable to rely on home tunneling for
optimizing multicast. Unencapsulated, native multicast transmission
requires establishing forwarding state, 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 - or its corresponding MAG in PMIPv6 - can perform remote
subscriptions in each visited network.
Schmidt, et al. Expires April 19, 2015 [Page 3]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
This document specifies extensions to FMIPv6 and PFMIPv6 that include
multicast traffic management for fast handover operations in the
presence of any-source or source-specific multicast. The protocol
extensions were designed under the requirements that
o multicast context transfer shall be transparently included in
unicast fast handover operations
o neither unicast mobility protocols nor multicast routing shall be
modified or otherwise affected
o no active participation of MNs in PMIPv6 domains is defined.
The solution common to both underlying unicast protocols defines the
per-group or per channel transfer of multicast contexts between ARs
or MAGs. The protocol defines corresponding message extensions
necessary for carrying (*,G) or (S,G) context information independent
of the particular handover protocol. ARs or MAGs are then enabled to
treat multicast traffic according to fast unicast handovers and with
similar performance. No protocol changes are introduced that prevent
a multicast unaware node from performing fast handovers with
multicast aware ARs or MAGs.
The specified mechanisms apply when a mobile node has joined and
maintains one or several multicast group subscriptions prior to
undergoing a fast handover. It does not introduce any requirements
on the 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.
Section 5.1 of this memo updates the Proxy Router Advertisements
(PrRtAdv) message format defined in Section 6.1.2. of [RFC5568] to
allow an FMIPv6 AR to indicate support for multicast.
1.1. Use Cases and Deployment Scenarios
Multicast Extensions for Fast Handovers enable multicast services in
those domains that operate any of the unicast fast handover protocols
[RFC5568] or [RFC5949]. Typically, fast handover protocols are
activated within an operator network or within a dedicated service
installation.
Multicast group communication has a variety of dominant use cases.
One traditional application area is infotainment with voluminous
multimedia streams delivered to a large number of receivers (e.g.,
IPTV). Other time-critical services are commonly transmitted via
Schmidt, et al. Expires April 19, 2015 [Page 4]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
multicast, such as include news items or stock-exchange prices, to
support fair and fast updates. Both may be mobile and both largely
benefit from fast handover operations. Mobile operators may
therefore enhance their operational quality or offer premium services
by enabling fast handovers.
Another traditional application area for multicast is conversational
group communication in scenarios like conferencing or gaming, but
also in dedicated collaborative environments or teams. Machine-to-
machine communication in the emerging Internet of Things is expected
to generate various additional mobile use cases (e.g., among cars).
High demands on transmission quality and rapidly moving parties may
require fast handovers.
Most of the deployment scenarios above are bound to a fixed
infrastructure with consumer equipment at the edge. Today, they are
thus likely to follow an operator-centric approach like PFMIPv6.
However, Internet technologies evolve for adoption in
infrastructureless scenarios, at disaster recovery, rescue, crisis
prevention and civil safety for example. Mobile end-to-end
communication in groups is needed in Public Protection and Disaster
Relief (PPDR) scenarios, where mobile multicast communication needs
to be supported between members of rescue teams, police officers,
fire brigade teams, paramedic teams, command control offices in order
to support the protection and health of citizens. These use cases
require fast and reliable mobile services which cannot rely on
operator infrastructure. They are thus expected to be benefit from
running multicast with FMIPv6.
2. Terminology
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].
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], [RFC5949],
[RFC6275], and [RFC5213] for mobility entities.
A multicast group is any group (S,G) or (*,G) or (S,G) multicast
channel listed in a Multicast Listener Report Message.
Schmidt, et al. Expires April 19, 2015 [Page 5]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
3. Protocol Overview
This section provides an informative overview of the protocol
mechanisms without normative specifications.
The reference scenario for multicast fast handover is illustrated in
Figure 1. A Mobile Node is initially attached to the previous access
network (P-AN) via the Previous Access Router (PAR) or Previous
Mobile Access Gateway (PMAG) and moves to the new access network
(N-AN) connected via a New AR (NAR) or New MAG (NMAG).
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover
3.1. Multicast Context Transfer between Access Routers
In a fast handover scenario (cf. Figure 1), 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 the forthcoming movement of an MN to a new AR
and assists the MN to immediately resume communication on the new
Schmidt, et al. Expires April 19, 2015 [Page 6]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
subnet using its previous IP address. In contrast to unicast,
multicast flow reception does not primarily depend on address and
binding cache management, but requires distribution trees to adapt so
that traffic follows the movement of the MN. This process may be
significantly slower than fast handover management [RFC5757]. To
accelerate the handover, a multicast listener may offer a twofold
advantage of including the multicast groups under subscription in the
context transfer: First, the NAR can proactively join the subscribed
groups as soon as it gains knowledge of them. Second, multicast
flows can be included in traffic forwarding via the tunnel that is
established from the PAR to the NAR by the unicast fast handover
protocol.
There are two modes of operation in FMIPv6 and in PFMIPv6. The
predictive mode allows for AR-binding and context transfer prior to
an MN handover, while in the reactive mode, these steps are executed
after detection that the MN has re-attached to a NAR (NMAG). Details
of the signaling schemes differ between FMIPv6 and PFMIPv6 and are
outlined in Section 3.2 and Section 3.3.
In a predictive fast handover, the access router (i.e., PAR (PMAG) in
Figure 1) learns about the impending movement of the MN and
simultaneously about the multicast group context as specified in
Section 3.2 and Section 3.3. Thereafter, the PAR will initiate an
AR-binding and context transfer by transmitting a HI message to NAR
(NMAG). The Handover Initiation (HI) message is extended by
multicast group states carried in mobility header options as defined
in Section 5.3. On reception of the HI message, the NAR returns a
multicast acknowledgement in its Handover Acknowledgement (HACK)
answer that indicates its ability to support each requested group
(see Section 5.4). The NAR (NMAG) expresses its willingness to
receive multicast traffic forwarded by the PAR using standard
Multicast Listener Discovery (MLD) signaling for IPv6, or the
Internet Group Management Protocol (IGMP) an IPv4 compatibility case.
Nodes normally create forwarding state for each group requested.
There are several reasons why a node may decide not to forward a
specific group, e.g., the NAR could already have a native
subscription for the group(s), or capacity constraints can hinder
decapsulation of additional streams. At the previous network, there
may be policy or capacity constraints that make it undesirable to
forward the multicast traffic. The PAR can add the tunnel interface
obtained from the underlying unicast protocol to its multicast
forwarding database for those groups the MN wishes to receive, so
that multicast flows can be forwarded in parallel to the unicast
traffic.
Schmidt, et al. Expires April 19, 2015 [Page 7]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
The NAR implements an MLD proxy [RFC4605] providing host-side
behaviour towards the upstream PAR. The proxy will submit an MLD
report to the upstream tunnel interface to signal the set of groups
to be forwarded. It will terminate multicast forwarding from the
tunnel when the group is natively received. In parallel, the NAR
joins all groups that are not already under subscription using its
native multicast upstream interface. While the MN has not arrived at
a downstream interface of the NAR, multicast subscriptions on behalf
of the MN are associated with a downstream Loopback interface.
Reception of the Join at the NAR enables downstream native multicast
forwarding of the subscribed group(s).
In a reactive fast handover, the 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 is
present at the new access network prior to context transfer, MLD join
signaling can proceed in parallel to HI/HACK exchange. Following the
context transfer, multicast data can be forwarded to the new access
network using the PAR-NAR tunnel of the fast handover protocol.
Depending on the specific network topology multicast traffic for some
groups may natively arrive before it is forwarded from the PAR.
In both modes of operation, it is the responsibility of the PAR
(PMAG) to properly apply multicast state management when an MN leaves
(i.e., to determine whether it can prune the traffic for any
unsubscribed group). Depending on the link type and MLD parameter
settings, methods for observing the departure of an MN need to be
applied (cf., [RFC5757]). While considering subscriptions of the
remaining nodes and from the tunnel interfaces, the PAR uses normal
multicast forwarding rules to determine whether multicast traffic can
be pruned.
This method allows an MN to participate in multicast group
communication with a handover performance that is comparable to
unicast handover. It is worth noting that tunnel management between
access routers in all modes is inherited from the corresponding
unicast fast handover protocols. Tunnels thus remain active until
unicast handover operations have been completed for the MN.
3.2. Protocol Operations Specific to FMIPv6
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. Additional details about the
multicast service support, e.g., flavors and groups, will be
exchanged within HI/HACK dialogs later at handover.
Schmidt, et al. Expires April 19, 2015 [Page 8]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
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) 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, the FBU is issued on the previous link and
received by the PAR as displayed in Figure 2. The PAR will extract
the multicast context options and append them to its HI message.
From the HACK message, the PAR will redistribute the multicast
acknowledgement by adding the corresponding mobility options to its
Fast Binding ACK (FBACK) message. From receiving the FBACK message,
the MN will learn about the multicast support for each group in the
new access network. If some groups or multicast service models are
not supported, it can decide to take actions to overcome a missing
service (e.g., by tunneling). Note that the proactive multicast
context transfer may proceed successfully, even if the MN misses the
FBACK message on the previous link.
Schmidt, et al. Expires April 19, 2015 [Page 9]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
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 optional |
| packet ================>|
| forwarding |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Multicast Handover for FMIPv6
The flow diagram for reactive mode is depicted in Figure 3. After
attaching to the new access link and performing an Unsolicited
Neighbor Advertisement (UNA), the MN issues an FBU which the NAR
forwards to the PAR without processing. At this time, the MN is able
to re-join all subscribed multicast groups without relying on AR
assistance. Nevertheless, multicast context options are exchanged in
the HI/HACK dialog to facilitate intermediate forwarding of the
requested multicast flows. The multicast traffic could arrive from
an MN subscription at the same time that the NAR receives the HI
message. Such multicast flows may be transparently excluded from
forwarding by setting an appropriate multicast acknowledge option.
In either case, to avoid duplication the NAR MUST ensure that not
more than one flow of the same group is forwarded to the MN.
Schmidt, et al. Expires April 19, 2015 [Page 10]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
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)|
| | |
| FBACK, optional |
| packet forwarding ==========>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Multicast Handover for FMIPv6
3.3. Protocol Operations Specific to PFMIPv6
In a proxy mobile IPv6 environment, the MN remains agnostic of
network layer changes, and fast handover procedures are operated by
the access routers or MAGs to which MNs are connected via node-
specific point-to-point links. The handover initiation, or the re-
association respectively are managed by the access networks.
Consequently, access routers need to be aware of multicast membership
state at the mobile node. There are two ways to obtain the multicast
membership of an MN.
o MAGs may perform explicit tracking (see [RFC4605], [RFC6224]) or
extract membership status from forwarding states at node-specific
links.
o routers can issue a general MLD query at handovers. Both methods
are equally applicable. However, a router that does not provide
Schmidt, et al. Expires April 19, 2015 [Page 11]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
explicit membership tracking needs to query its downstream links
after a handover. The MLD membership information then allows the
PMAG to learn the multicast group subscriptions of the MN.
In predictive mode, the PMAG will learn about the upcoming movement
of the mobile node including its new Access Point Identifier (New AP
ID). Without explicit tracking, it will immediately submit a general
MLD query and receive MLD reports indicating the multicast address
listening state of the subscribed group(s). As displayed in
Figure 4, it will initiate binding and context transfer with the NMAG
by issuing a HI message that is augmented by multicast contexts in
the mobility options defined in Section 5.3. NMAG will extract
multicast context information and act as described in Section 3.1.
Schmidt, et al. Expires April 19, 2015 [Page 12]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|---(MN ID,-->| | | |
| New AP ID) | | | |
| | HO Indication | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HACK-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HACK(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
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 will learn the attachment of the MN to the
N-AN and establish connectivity using the PMIPv6 protocol operations.
However, it will have no knowledge about multicast state at the MN.
Triggered by an MN attachment, the NMAG will send a general MLD query
and thereafter join the groups for which it receives multicast
listener report messages. In the case of a reactive handover, the
binding is initiated by the NMAG, and the HI/HACK message semantic is
inverted (see [RFC5949]). For multicast context transfer, the NMAG
Schmidt, et al. Expires April 19, 2015 [Page 13]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
attaches to its HI message those group identifiers it requests to be
forwarded from PMAG. Using the identical syntax in its multicast
mobility option headers as defined in Section 5.4, the PMAG
acknowledges the set of requested groups in a HACK answer, indicating
the group(s) it is willing to forward. The corresponding call flow
is displayed in Figure 5.
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)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
| | | | |
|<======================================== deliver packets
| | | | |
Figure 5: Reactive Multicast Handover for PFMIPv6
Schmidt, et al. Expires April 19, 2015 [Page 14]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
4. Protocol Details
This section provides a normative definition of the protocol
operations.
4.1. Protocol Operations Specific to FMIPv6
4.1.1. Operations of the Mobile Node
A Mobile Node willing to manage multicast traffic by fast handover
operations MUST transfer its MLD listener state records within fast
handover negotiations.
When sensing a handover in predictive mode, an MN MUST build a
Multicast Mobility Option as described in Section 5.3 that contains
the MLD or IGMP multicast listener state and append it to the Fast
Binding Update (FBU) prior to signaling with PAR.
The MN will receive the Multicast Acknowledgement Option(s) as a part
of the Fast Binding Acknowledge (FBACK) (see Section 5.4) and learn
about unsupported or prohibited groups at the NAR. The MN MAY take
appropriate actions such as home tunneling to enable reception of
groups that are not available via the NAR. No multicast-specific
operation is required by the MN when re-attaching in the new network
beyond standard FMIPv6 signaling.
In reactive mode, the MN MUST append the identical Multicast Mobility
Option to the FBU sent after its reconnect. In response, it will
learn about the Multicast Acknowledgement Option(s) from the FBACK
and expect corresponding multicast data. Concurrently it joins all
subscribed multicast groups directly on its newly-established access
link.
4.1.2. Operations of the Previous Access Router
A PAR that supports multicast advertises that support by setting the
M-bit in the Proxy Router Advertisement (PrRtAdv) message, as
specified in Section 5.1 of this document. This indicator
exclusively informs the MNs about the capability of the PAR to
process and exchange Multicast Mobility Options during Fast Handover
operations.
In predictive mode, a PAR will receive the multicast listener state
of an MN prior to handover from the Multicast Mobility Option
appended to the FBU. It forwards these records to the NAR within HI
messages and will expect Multicast Acknowledgement Option(s) in a
HACK, which is itself returned to the MN as an appendix to the FBACK.
In performing the multicast context exchange, the PAR is instructed
Schmidt, et al. Expires April 19, 2015 [Page 15]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
to include the PAR-to-NAR tunnel obtained from unicast handover
management in its multicast downstream interfaces and awaits
reception of multicast listener report messages from the NAR. In
response to receiving multicast subscriptions, the PAR SHOULD forward
group data acting as a regular multicast router or proxy. However,
the PAR MAY refuse to forward some or all of the multicast flows
(e.g., due to administrative configurations or load conditions).
In reactive mode, the PAR will receive the FBU augmented by the
Multicast Mobility Option from the new network, but continues with an
identical multicast record exchange in the HI/HACK dialog. As in the
predictive case, it configures the PAR-to-NAR tunnel for the
multicast downstream. It then (if capable) forwards data according
to the group membership indicated in the multicast listener report
messages received from NAR.
In both modes, the PAR MUST interpret the first of the two events -
the departure of the MN or the reception of the Multicast
Acknowledgement Option(s) - as if the MN had sent a multicast LEAVE
message and react according to the signaling scheme deployed in the
access network (i.e., MLD querying, explicit tracking).
4.1.3. Operations of the New Access Router
A NAR that supports multicast advertises that support by setting the
M-bit in PrRtAdv as specified in Section 5.1 of this document. This
indicator exclusively serves the purpose of informing MNs about the
capability of the NAR to process and exchange Multicast Mobility
Options during Fast Handover operations.
In predictive mode, a NAR will receive the multicast listener state
of an expected MN from the Multicast Mobility Option appended to the
HI message. It will extract the multicast group membership records
from the message and match the request subscription with its
multicast service offer. Further on it will join the requested
groups using a downstream Loopback interface. This will lead to
suitable regular subscriptions to a native multicast upstream
interface without additional forwarding. Concurrently, the NAR
builds a Multicast Acknowledgement Option(s) (see Section 5.4)
listing the set of groups that are unsupported on the new access link
and returns this list within a HACK. As soon as there is an
operational bidirectional tunnel from the PAR to NAR, the NAR joins
the groups requested by the MN, which are then forwarded by the PAR
using the tunnel link.
In reactive mode, the NAR will learn about the multicast listener
state of a new MN from the Multicast Mobility Option appended to each
HI message, after the MN has already performed local subscriptions of
Schmidt, et al. Expires April 19, 2015 [Page 16]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
the multicast service. Thus the NAR solely determines the
intersection of requested and supported groups and issues a join
request for each group forwarding this on the PAR-NAR tunnel
interface.
In both modes, the NAR MUST send a LEAVE message to the tunnel when
it is no longer needed to forward a group, e.g., after native
multicast traffic arrives or termination of a group membership from
the MN. Although the message can be delayed, immediately sending the
LEAVE message eliminates the need for PAR and NAR to process traffic
that is not to be forwarded.
4.1.4. Buffering Considerations
Multicast packets may be lost during handover. For example, in
predictive mode as illustrated by figure 2, packets may be lost while
the MN is - already or still - detached from the networks, even
though they are forwarded to the NAR. In reactive mode as
illustrated by figure 3, the situation may be worse, since there will
be a delay before joining the multicast group after the MN re-
attaches to the NAR. Multicast packets cannot be delivered during
this time. Buffering the multicast packets at the PAR can reduce
multicast packet loss, but may then increase resource consumption and
delay in packet transmission. Implementors should balance the
different requirements in the context of predominant application
demands (e.g., real-time requirements, or loss sensitivity).
4.2. Protocol Operations Specific to PFMIPv6
4.2.1. Operations of the Mobile Node
A Mobile Node willing to participate in multicast traffic will join,
maintain and leave groups as if located in the fixed Internet. It
will cooperate in handover indication as specified in [RFC5949] and
required by its access link-layer technology. No multicast-specific
mobility actions nor implementations are required at the MN in a
PMIPv6 domain.
4.2.2. Operations of the Previous MAG
A MAG receiving a handover indication for one of its MNs follows the
same predictive fast handover mode as a PMAG. It MUST issue an MLD
General Query immediately on its corresponding link unless it
performs explicit membership tracking on that link. After knowledge
of the multicast subscriptions of the MN is acquired, the PMAG builds
a Multicast Mobility Option, as described in Section 5.3 that
contains the MLD and IGMP multicast listener state. If not empty,
this Mobility Option is appended to the regular fast handover HI
Schmidt, et al. Expires April 19, 2015 [Page 17]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
messages. In the case when a unicast HI message is submitted prior
to multicast state detection, the multicast listener state is sent in
an additional HI message to the NMAG.
The PMAG then waits until it receives the Multicast Acknowledgement
Option(s) with a HACK message (see Section 5.4) and the creation of
the bidirectional tunnel with NMAG. After the HACK message is
received, the PMAG adds the tunnel to its downstream interfaces in
the multicast forwarding database. For those groups reported in the
Multicast Acknowledgement Option(s), i.e., not supported in the new
access network, the PMAG normally takes appropriate actions (e.g.,
forwarding, termination) according to the network policy. It SHOULD
start forwarding multicast traffic down the tunnel interface for
those groups for the groups indicated in the multicast listener
reports received from NMAG. However, it MAY deny forwarding some or
all groups included in the multicast listener reports (e.g., due to
administrative configurations or load conditions).
After the departure of the MN and on the reception of a LEAVE
message, it is RECOMMENDED that the PMAG terminates forwarding of the
specified groups and updates its multicast forwarding database. It
correspondingly sends a LEAVE message to its upstream link for any
group where there are no longer any active listeners on any
downstream link.
A MAG receiving a HI message with the Multicast Mobility Option for a
currently attached node follows the reactive fast handover mode as a
PMAG. It will return Multicast Acknowledgement Option(s) (see
Section 5.4) within a HACK message listing the groups for which it
does not provide forwarding support to the NMAG. It will add the
bidirectional tunnel with NMAG to its downstream interfaces and will
start forwarding multicast traffic for the groups listed in the
multicast listener report messages from the NMAG. On reception of a
LEAVE message for a group, the PMAG terminates forwarding for the
specific group and update its multicast forwarding database.
According to its multicast forwarding state, It sends a LEAVE message
to its upstream link for any group where there are no longer any
active listeners on any downstream link.
In both modes, the PMAG will interpret the departure of the MN as a
multicast LEAVE message of the MN and react according to the
signaling scheme deployed in the access network (i.e., MLD querying,
explicit tracking).
Schmidt, et al. Expires April 19, 2015 [Page 18]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
4.2.3. Operations of the New MAG
A MAG receiving a HI message with a Multicast Mobility Option for a
currently unattached node follows the same predictive fast handover
mode as an NMAG. It will decide the multicast groups to be forwarded
from the PMAG and build a Multicast Acknowledgement Option (see
Section 5.4) that enumerates only unwanted groups. This Mobility
Option is appended to the regular fast handover HACK messages, or -
in the case of a unicast HACK message being submitted prior to
multicast state acknowledgement - sent in an additional HACK message
to the PMAG. Immediately thereafter, the NMAG SHOULD update its MLD
membership state based on the membership reported in the Multicast
Mobility Option. Until the MN re-attaches, the NMAG uses its
Loopback interface for downstream and MUST NOT forward traffic to the
potential link of the MN. The NMAG SHOULD issue JOIN messages for
those newly selected groups to its regular multicast upstream
interface. As soon as the bidirectional tunnel with PMAG is
established, the NMAG additionally joins those groups on the tunnel
interface requested to be forwarded from the PMAG.
A MAG experiencing a connection request for an MN without prior
reception of a corresponding Multicast Mobility Option is operating
in the reactive fast handover mode as an NMAG. Following the re-
attachment, it SHOULD immediately issue an MLD General Query to learn
about multicast subscriptions of the newly arrived MN. Using
standard multicast operations, the NMAG joins groups not currently
forwarded using its regular multicast upstream interface.
Concurrently, it selects groups for forwarding from PMAG and builds a
Multicast Mobility Option as described in Section 5.3 that contains
the multicast listener state. If not empty, this Mobility Option is
appended to the regular fast handover HI messages with the F flag
set, or - in the case of unicast HI message being submitted prior to
multicast state detection - sent in an additional HI message to the
PMAG. Upon reception of the Multicast Acknowledgement Option and
establishment of the bidirectional tunnel, the NMAG additionally
joins the set of groups on the tunnel interface that it wishes to
receive by forwarding from the PMAG. When multicast flows arrive,
the NMAG forwards data to the appropriate downlink(s).
In both modes, the NMAG MUST send a LEAVE message to the tunnel when
forwarding of a group is no longer needed, e.g., after native
multicast traffic arrives or group membership of the MN terminates.
Although the message can be delayed, immediately sending the LEAVE
message eliminates the need for PAR and NAR to process traffic that
is not to be forwarded.
Schmidt, et al. Expires April 19, 2015 [Page 19]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
4.2.4. IPv4 Support Considerations
An MN in a PMIPv6 domain MAY use an IPv4 address transparently for
communication as specified in [RFC5844]. For this purpose, LMAs can
register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide
IPv4 support in access networks. Correspondingly, multicast
membership management will be performed by the MN using IGMP. For
multi-protocol multicast support on the network side, IGMPv3 router
functions are required at both MAGs (see Section 5.6 for
compatibility considerations with previous IGMP versions). Context
transfer between MAGs can transparently proceed in the HI/HACK
message exchanges by encapsulating IGMP multicast state records
within Multicast Mobility Options (see Section 5.3 and Section 5.4
for details on message formats).
The deployment of IPv4 multicast support SHOULD be homogeneous across
a PMIP domain. This avoids multicast service breaks during
handovers.
It is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access
network, and the use of GRE tunneling as specified in[RFC5845].
Corresponding implications and operations are discussed in the PMIP
Multicast Base Deployment document, see[RFC6224].
5. Message Formats
5.1. Multicast Indicator for Proxy Router Advertisement (PrRtAdv)
This document updates the Proxy Router Advertisements (PrRtAdv)
message format defined in Section 6.1.2. of [RFC5568]. The update
assigns the first bit of the Reserved field, to carry the 'M' bit, as
defined in Figure 6. An FMIPv6 AR indicates support for multicast by
assigning the setting 'M' bit to a value of 1.
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
Schmidt, et al. Expires April 19, 2015 [Page 20]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
This document updates the reserved field to include the 'M' bit
specified as follows.
M = 1 indicates that the specifications of this document apply
M = 0 indicates that the behaviour during Fast Handover proceeds
according to [RFC5568].
The default value (0) of this bit indicates a non-multicast capable
service.
5.2. Extensions to Existing Mobility Header Messages
The fast handover protocols use an IPv6 header type called Mobility
Header as defined in [RFC6275]. Mobility headers can carry variable
Mobility Options.
The 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 MUST be acknowledged by a corresponding
Multicast 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).
5.3. New Multicast Mobility Option
This section defines the Multicast Mobility Option. It contains the
current listener state record of the MN obtained from the MLD
Multicast Listener Report message, and has the format displayed in
Figure 7.
Schmidt, et al. Expires April 19, 2015 [Page 21]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
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 or IGMP Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Mobility Header Multicast Option
XXX RFC Editor note: IANA is requested to allocate the value TBD1 and
remove this note prior to publication.
Type: TBD1
Length: 8-bit unsigned integer. The length of this option in 32 bit
words, not including the Option Type, Option Length, Option-Code and
Reserved fields.
Option-Code:
1: IGMPv3 Payload Type
2: MLDv2 Payload Type
3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode
4: MLDv2 Payload Type from MLDv1 Compatibility Mode
Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.
MLD or IGMP Report Payload: this field is composed of the Membership
Report message after stripping its ICMP header. This Report Payload
always contains an integer number of multicast records.
Corresponding message formats are defined for MLDv2 in [RFC3810], and
for IGMPv3 in [RFC3376]. This field MUST always contain the first
header line (reserved field and No of Mcast Address Records).
Schmidt, et al. Expires April 19, 2015 [Page 22]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
Figure 8 shows the Report Payload for MLDv2, while the payload format
for IGMPv3 is defined corresponding to the IGMPv3 payload format (see
Section 5.2. of [RFC3810], or Section 4.2 of [RFC3376] 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 |No of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast Address Record (1) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (2) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (M) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MLDv2 Report Payload
5.4. New Multicast Acknowledgement Option
The Multicast Acknowledgement Option reports the status of the
context transfer and contains the list of state records that could
not be successfully transferred to the next access network. It has
the format displayed in Figure 9.
Schmidt, et al. Expires April 19, 2015 [Page 23]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
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 or IGMP Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Mobility Header Multicast Acknowledgement Option
XXX RFC Editor note: IANA is requested to allocate the value TBD2 and
remove this note prior to publication.
Type: TBD2
Length: 8-bit unsigned integer. The length of this option in 32 bit
words, not including the Option Type, Option Length, Option-Code and
Status fields.
Option-Code: 0
Status:
1: Report Payload type unsupported
2: Requested group service unsupported
3: Requested group service administratively prohibited
MLD or IGMP Unsupported Report Payload: this field is syntactically
identical to the MLD and IGMP Report Payload field described in
Section 5.3, 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
No of Mcast Address Records), but MUST NOT contain any Mcast Address
Records, if the status code equals 1.
Note that group subscriptions to specific sources may be rejected at
the destination network, and thus the composition of multicast
Schmidt, et al. Expires April 19, 2015 [Page 24]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
address records may differ from initial requests within an MLD or
IGMP Report Payload option.
5.5. Length Considerations: Number of Records and Addresses
Mobility Header Messages exchanged in HI/HACK and FBU/FBACK dialogs
impose length restrictions on multicast context records due to the 8
bit Length field. The maximal payload length available in FBU/FBACK
messages is 4 octets (Mobility Option header line) + 1024 octets (MLD
Report Payload). For example, not more than 51 Multicast Address
Records of minimal length (without source states) may be exchanged in
one message pair. In typical handover scenarios, this number reduces
further according to unicast context and Binding Authorization data.
A larger number of MLD Reports that exceeds the available payload
size MAY be sent within multiple HI/HACK or FBU/FBACK message pairs.
In PFMIPv6, context information can be fragmented over several HI/
HACK messages. However, a single MLDv2 Report Payload MUST NOT be
fragmented. Hence, for a single Multicast Address Record, the number
of source addresses (S,.) is limited to 62.
5.6. MLD and IGMP Compatibility Requirements
Access routers (MAGs) MUST support MLDv2 and IGMPv3. To enable
multicast service for MLDv1 and IGMPv2 listeners, the routers MUST
follow the interoperability rules defined in [RFC3810] and [RFC3376],
and appropriately set the Multicast Address Compatibility Mode.
When the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, a
router internally translates the following MLDv1 and IGMPv2 messages
for that multicast address to their MLDv2 and IGMPv3 equivalents and
uses these messages in the context transfer. The current state of
Compatibility Mode is translated into the code of the Multicast
Mobility Option as defined in Section 5.3. A NAR (NMAG) receiving a
Multicast Mobility Option during handover will switch to the lowest
level of MLD and IGMP Compatibility Mode that it learned from its
previous and new option values. This minimal compatibility agreement
is used to allow for continued operation.
6. Security Considerations
Security vulnerabilities that exceed issues discussed in the base
protocols of this document ([RFC5568], [RFC5949], [RFC3810],
[RFC3376]) are identified as follows.
Multicast context transfer at predictive handovers implements group
states at remote access routers and may lead to group subscriptions
without further validation of the multicast service requests.
Thereby a NAR (NMAG) is requested to cooperate in potentially complex
Schmidt, et al. Expires April 19, 2015 [Page 25]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
multicast re-routing and may receive large volumes of traffic.
Malicious or inadvertent multicast context transfers may result in a
significant burden of route establishment and traffic management onto
the backbone infrastructure and the access router itself. Rapid re-
routing or traffic overload can be mitigated by a rate control at the
AR that restricts the frequency of traffic redirects and the total
number of subscriptions. In addition, the wireless access network
remains protected from multicast data injection until the requesting
MN attaches to the new location.
7. IANA Considerations
This document defines two new mobility options which need allocation
from the Mobility Header Type registry at
http://www.iana.org/assignments/mobility-parameters.
XXX RFC Editor note: IANA is requested to allocate the values TBD1
and TBD2 and remove this note prior to publication.
TBD1 Multicast Mobility Option, described in Section 5.3
TBD2 Multicast Acknowledgement Option, described in Section 5.4
RFC Editor note: The RFC Editor is requested to replace "TBD*" by the
IANA-assigned value prior to publication and may then remove this
note.
8. Acknowledgments
Protocol extensions to support multicast in Fast Mobile IPv6 have
been loosely discussed for several years. Repeated attempts have
been taken to define corresponding protocol extensions. The first
draft [fmcast-mip6] was presented by Suh, Kwon, Suh, and Park in
2004.
This work was stimulated by many fruitful discussions in the MobOpts
research group. We would like to thank all active members for
constructive thoughts and contributions on the subject of multicast
mobility. The MULTIMOB working group has provided continuous
feedback during the evolution of this work. Comments, discussions,
and reviewing remarks have been contributed by (in alphabetical
order) Carlos J. Bernardos, Luis M. Contreras, Hui Deng, Shuai Gao,
Brian Haberman, Dirk von Hugo, Min Hui, Georgios Karagian, Marco
Liebsch, Behcet Sarikaya, Stig Venaas and Juan Carlos Zuniga.
Funding has been provided by the German Federal Ministry of Education
and Research within the projects Mindstone, SKIMS and SAFEST, which
is gratefully acknowledged.
Schmidt, et al. Expires April 19, 2015 [Page 26]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July
2009.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
9.2. Informative References
[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.
[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.
Schmidt, et al. Expires April 19, 2015 [Page 27]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
[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.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC7287] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile
Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6)
Domains", RFC 7287, June 2014.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, June 2010.
Appendix A. Considerations for Mobile Multicast Sources
This document specifies protocol operations for a fast handover of
mobile listeners, only. In this appendix, we briefly discuss aspects
of supporting mobile multicast sources.
In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender
support is likely to be enabled by any one of the mechanisms
described in [RFC7287]. In this case, multicast data packets from an
MN are transparently forwarded either to its associated LMA or to a
multicast-enabled access network. In all cases, a mobile source can
continue to transmit multicast packets after a handover from PMAG to
NMAG without additional management operations. Packets (with a
persistent source address) will continue to flow via the LMA or the
access network into the previously established distribution system.
In contrast, an MN will change its Care-of Address while performing
FMIPv6 handovers. Even though MNs are enabled to send packets via
the reverse NAR-PAR tunnel using their previous Care-of Address for a
limited time, Multicast sender support in such a Mobile IPv6 regime
will most likely follow one of the basic mechanisms (1) bidirectional
tunneling, (2) remote subscription, or (3) agent-based as described
in Section 5.1 of [RFC5757]. A solution for multicast senders that
is homogeneously deployed throughout the mobile access network can
support seamless services during Fast Handovers, the details of which
are beyond the scope of this document.
Schmidt, et al. Expires April 19, 2015 [Page 28]
Internet-Draft Multicast for FMIPv6/PFMIPv6 October 2014
Authors' Addresses
Thomas C. Schmidt (editor)
HAW Hamburg
Dept. Informatik
Berliner Tor 7
Hamburg D-20099
Germany
Email: t.schmidt@haw-hamburg.de
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin D-10318
Germany
Email: mw@link-lab.net
Rajeev Koodli
Intel
3600 Juliette Lane
Santa Clara, CA 95054
USA
Email: rajeev.koodli@intel.com
Godred Fairhurst
University of Aberdeen
School of Engineering
Aberdeen AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Dapeng Liu
China Mobile
Phone: +86-123-456-7890
Email: liudapeng@chinamobile.com
Schmidt, et al. Expires April 19, 2015 [Page 29]
