PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)
draft-ietf-multimob-fast-handover-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Luis M. Contreras , Carlos J. Bernardos , Ignacio Soto | ||
| Last updated | 2012-05-22 | ||
| Replaced by | draft-ietf-multimob-handover-optimization, RFC 7161 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-multimob-fast-handover-00
MULTIMOB Working Group LM. Contreras
Internet-Draft Telefonica I+D
Intended status: Experimental CJ. Bernardos
Expires: November 23, 2012 UC3M
I. Soto
UPM
May 22, 2012
PMIPv6 multicast handover optimization by the Subscription Information
Acquisition through the LMA (SIAL)
draft-ietf-multimob-fast-handover-00
Abstract
This document specifies a multicast handover optimization mechanism
for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic
to mobile nodes after handovers. The mechanism is based on speeding
up the acquisition of mobile nodes' active multicast subscriptions
information by the mobile access gateways. To do that, extensions to
the current Proxy Mobile IPv6 protocol are proposed. These
extensions are not only applicable to the base solution for multicast
support in Proxy Mobile IPv6, but also can be applied to other
solutions envisioned as possible architectural evolutions of it.
Furthermore, they are also independent of the role played by the
mobile access gateway within the multicast network (either acting as
multicast listener discovery proxy or multicast router).
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/.
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 November 23, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Contreras, et al. Expires November 23, 2012 [Page 1]
Internet-Draft PMIPv6 multicast handover optimization May 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . . 7
4.1. New mobility option . . . . . . . . . . . . . . . . . . . 7
4.1.1. Active Multicast Subscription mobility option . . . . 7
4.1.1.1. Option application rules . . . . . . . . . . . . . 7
4.1.1.2. Option format . . . . . . . . . . . . . . . . . . 7
4.2. New flags . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Multicast Signaling flag on PBU/PBA message headers . 8
4.2.1.1. Flag application rules . . . . . . . . . . . . . . 8
4.2.1.1.1. Registration process . . . . . . . . . . . . . 9
4.2.1.1.2. De-registration process . . . . . . . . . . . 10
4.2.1.2. New format of conventional PBU/PBA messages . . . 10
4.2.1.2.1. Proxy Binding Update message . . . . . . . . . 10
4.2.1.2.2. Proxy Binding Acknowledgement Message . . . . 11
4.2.2. Multicast Active flag in the LMA Binding Cache and
(optionally) on the MN's policy store . . . . . . . . 11
4.2.2.1. Flag application rules . . . . . . . . . . . . . . 11
4.3. New messages . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.1. Messages for active multicast subscription
interrogation . . . . . . . . . . . . . . . . . . . . 12
4.3.1.1. Subscription Query message . . . . . . . . . . . . 12
4.3.1.1.1. Message application rules . . . . . . . . . . 12
4.3.1.1.2. Message format . . . . . . . . . . . . . . . . 13
4.3.1.2. Subscription Response message . . . . . . . . . . 14
4.3.1.2.1. Message application rules . . . . . . . . . . 14
4.3.1.2.2. Message format . . . . . . . . . . . . . . . . 14
4.3.2. Messages for active multicast subscription
indication . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2.1. Multicast Activity Indication message . . . . . . 15
4.3.2.1.1. Message application rules . . . . . . . . . . 15
4.3.2.1.2. Message format . . . . . . . . . . . . . . . . 15
Contreras, et al. Expires November 23, 2012 [Page 2]
Internet-Draft PMIPv6 multicast handover optimization May 2012
4.3.2.2. Multicast Activity Indication Acknowledge
message . . . . . . . . . . . . . . . . . . . . . 17
4.3.2.2.1. Message application rules . . . . . . . . . . 17
4.3.2.2.2. Message format . . . . . . . . . . . . . . . . 17
4.4. New PBA timer in the LMA . . . . . . . . . . . . . . . . . 18
5. Signaling processes description . . . . . . . . . . . . . . . 18
5.1. Multicast Activity signaling . . . . . . . . . . . . . . . 18
5.1.1. Multicast Activity set to ON (A=1) . . . . . . . . . . 18
5.1.2. Multicast Activity set to OFF (A=0) . . . . . . . . . 19
5.2. Handover signaling procedures . . . . . . . . . . . . . . 20
5.2.1. Handover of proactive type . . . . . . . . . . . . . . 20
5.2.1.1. Rationale . . . . . . . . . . . . . . . . . . . . 20
5.2.1.2. Message flow description . . . . . . . . . . . . . 21
5.2.2. Handover of reactive type . . . . . . . . . . . . . . 23
5.2.2.1. Rationale . . . . . . . . . . . . . . . . . . . . 23
5.2.2.2. Message flow description . . . . . . . . . . . . . 24
5.2.2.3. Further considerations for the reactive
handover signaling . . . . . . . . . . . . . . . . 27
5.2.3. LMA decision process . . . . . . . . . . . . . . . . . 27
5.2.3.1. LMA processing of S flag on reception of PBU
messages . . . . . . . . . . . . . . . . . . . . . 27
5.2.3.1.1. Proactive handover . . . . . . . . . . . . . . 28
5.2.3.1.2. Reactive handover . . . . . . . . . . . . . . 28
5.2.3.2. LMA set-up of S flag in PBA messages . . . . . . . 29
5.2.4. Prevention of large delays of the binding
acknowledgement for unicast traffic . . . . . . . . . 30
6. Co-existence with PMIPv6 multicast architectural evolutions . 34
7. Benefits of layer-2 triggers for fast handover . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Contreras, et al. Expires November 23, 2012 [Page 3]
Internet-Draft PMIPv6 multicast handover optimization May 2012
1. Introduction
The base solution describing how continuous multicast service
delivery can be provided in Proxy Mobile IPv6 domains is described in
RFC 6224 [RFC6224]. This solution specifies the basic functionality
needed in the Proxy Mobile IPv6 [RFC5213] entities to provide a
multicast service, and supports the continuous delivery of multicast
traffic by obtaining, after a handover, the on-going multicast
subscription information directly from the mobile node. When a
mobile node attaches to a new mobile access gateway, the mobile node
is interrogated by the mobile access gateway through a multicast
listener discovery General Query, which is sent just after any new
link is set up, to get knowledge of any existing subscription, as
specified in [RFC2710].
However, as highlighted by [I-D.von-hugo-multimob-future-work], the
base solution needs to be improved to meet some performance
requirements, especially those referred to the user perceived service
quality, which is seriously affected by the disruption of multicast
content forwarding to the mobile node during handovers.
A mobile node with an active multicast subscription, moving from one
point of attachment to another within a Proxy Mobile IPv6 domain,
experiences a certain delay until it resumes receiving again the
multicast content that it was receiving at the previous location.
Such delay causes a gap in the content reception. Two different
actions can help to mitigate such reception gap. One of them is to
buffer at the previous mobile access gateway the traffic with
destination at the mobile node and forward it to the new mobile
access gateway, in order to deliver that traffic to the mobile node.
The other possible (complementary) action is to reduce the time
needed by the new mobile access gateway to get knowledge of the
active multicast subscription of the mobile node (i.e., the IP
addresses of the multicast groups subscribed and the sources
providing them), so the new mobile access gateway can subscribe to
the multicast group(s) on behalf of the mobile node as soon as
possible.
While the first mechanism can be accomplished by using [RFC5949] or
some evolution of it (despite being only applicable in the case the
underlying radio access technology supports layer-2 triggers, and it
requires additional support on the mobile node), there is no a
generic standard solution for the accelerated acquisition of the on-
going multicast subscription of the mobile node.
The approach followed by the base solution [RFC6224] to get knowledge
of an existing multicast subscription relies on the behavior of the
IGMP/MLD protocols. Both protocols send multicast membership
Contreras, et al. Expires November 23, 2012 [Page 4]
Internet-Draft PMIPv6 multicast handover optimization May 2012
interrogation messages when a new link is up. The response to that
request reports any existing multicast subscription by the mobile
node. While this is a straightforward approach, it also causes that
the mobile access gateway can incur in a non-negligible delay in
receiving the corresponding MLD Report message. This delay is caused
by the time needed for the detection of the attachment in the new
link, the radio transfer delays associated with the signaling to the
mobile node, and the MLD query response interval time required by
this procedure (whose default value is 10 seconds as defined in
[RFC2710], or between 5 and 10 seconds as considered in the best case
wireless link scenario in [RFC6636]).
This document extends the Proxy Mobile IPv6 signaling protocol
defined in the base protocol [RFC5213] by including a new multicast
information option to update Proxy Mobile IPv6 entities during the
registration and de-registration processes, and new messages to
trigger the transfer of multicast information. No extension is
required in any of the multicast-related protocols in use (IGMP/MLD
or PIM protocols). This document provides a signaling method
internal to the network to speed up the subscription information
acquisition by the mobile access gateway, in order to accelerate the
multicast delivery to the mobile node after having completed a
handover. By doing so, the knowledge by the mobile access gateway of
the currently active multicast subscription becomes independent of
the underlying radio technology dynamics and relaxes the requirement
of a rapid response from the mobile node in processing MLD control
messages. Issues like radio framing, radio access contention,
channel reliability, MN's capabilities (i.e., layer-2 triggering
support), IGMP/MLD timers optimization for wireless environments,
etc, do not impact on the observed multicast performance during
handovers.
The solution described in this document is not only applicable to the
base solution defined in [RFC6224], but also it can be applied to
other solutions envisioned as possible architectural evolutions of
it, as those stated in [I-D.ietf-multimob-pmipv6-ropt]. Furthermore,
it is also independent of the role played by the mobile access
gateway within the multicast network (either acting as MLD proxy or
multicast router).
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 RFC2119 [RFC2119].
This document uses the terminology referring to PMIPv6 components as
Contreras, et al. Expires November 23, 2012 [Page 5]
Internet-Draft PMIPv6 multicast handover optimization May 2012
defined in [RFC5213].
Additionally, the following terms are defined.
pMAG The previous MAG or pMAG is the MAG where the MN is initially
registered in a handover event.
Reactive Handover A reactive handover is a handover event in which
the LMA receives the MN registration from the nMAG without having
previously received the MN de-registration from the pMAG.
Proactive handover A proactive handover is a handover event where
the LMA receives the MN de-registration from the pMAG previously
to receive the MN registration from the nMAG.
3. Overview
The LMA is a key element within the PMIPv6 infrastructure, which
traces the MN reachability along the PMIPv6 domain. Therefore the
LMA is the best element to maintain the MNs' multicast subscription
information updated and to forward it to the rest of PMIPv6 entities
(i.e., to the MAGs) as needed when MNs move within the domain. The
LMA has timely knowledge of the MNs' location, especially during
handover events, and it is therefore able to quickly provide
information to the new one point of attachment (querying the previous
one if required).
The LMA only obtains the detailed subscription information (in terms
of the IP addresses of both the multicast group subscribed, G, and
the source delivering it, S) during a handover event. There is no
need of continuously informing the LMA about MNs' multicast state
while the mobile nodes remain attached to the same mobile access
gateway. Such a continuous updating procedure would significantly
increase the signaling load within the PMIPv6 domain without a clear
benefit. The subscription information (S,G) is only critical during
handovers, neither after nor before. Indicating the active
subscription while the handover is ongoing guarantees that such
information will be up-to-date, ready to be transferred to the new
MAG where the MN has just attached.
To be able to transfer the multicast subscription information between
PMIPv6 entities during a handover, this document extends the PMIPv6
protocol in several ways. First of all, a new mobility option is
defined to carry the IP addresses of the current multicast
subscription. Furthermore, additional messages are defined to manage
the interchange of the multicast information among PMIPv6 entities.
Finally, some flags are defined to govern the process.
Contreras, et al. Expires November 23, 2012 [Page 6]
Internet-Draft PMIPv6 multicast handover optimization May 2012
Next sections provide the details of these Proxy Mobile IPv6 protocol
extensions.
4. PMIPv6 extensions
This section outlines the extensions proposed to the PMIPv6 protocol
specified in [RFC5213].
4.1. New mobility option
4.1.1. Active Multicast Subscription mobility option
4.1.1.1. Option application rules
A new TLV-encoded mobility option, "Active Multicast Subscription"
option is defined for use with the PBU (Proxy Binding Update) and PBA
(Proxy Binding Acknowledge) messages exchanged between an LMA and a
MAG to transfer the multicast subscription information. This option
is used for exchanging the IP addresses of both the group subscribed
to by the MN, and the source delivering it. There can be multiple
"Active Multicast Subscription" options present in the message, one
for each active subscription maintained by the MN when the handover
is taking place.
This option does not include specific information about the
applicable filter mode defined in [RFC3810]. After the handover
process, the MN has to receive the same multicast flow being received
before the handover initiation (in terms of the (S,G) duple), then
the filter mode information is not strictly critical to accelerate
the reception of the multicast flow at the new point of attachment.
This information can be, however, retrieved later through the
response message to the MLD Query sent by the nMAG once the point-to-
point link of the entering MN is set-up, as defined in [RFC6224].
This new option will be also used, with the same aim, by the new
message Subscription Response described later in this document.
4.1.1.2. Option format
The format of this new option is as follows:
Contreras, et al. Expires November 23, 2012 [Page 7]
Internet-Draft PMIPv6 multicast handover optimization May 2012
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Source IP address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Group IP address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
To be defined by IANA.
Length:
8-bit unsigned integer indicating the length of the option in
octects, excluding the type and length fields. This field must be
set to the value 8 for IPv4, and 32 for IPv6.
Multicast Source IP address:
Unicast IP address of the node which injects the multicast content
in the network. Multicast Group IP address.
Multicast Group IP address:
Multicast IP address identifying the content which the MN
subscribes to.
4.2. New flags
Two new flags are defined and used to handle the forwarding of
multicast subscription information.
4.2.1. Multicast Signaling flag on PBU/PBA message headers
4.2.1.1. Flag application rules
A new flag S is added in both PBU and PBA message headers to advise
about the MAG and the LMA capabilities of processing multicast-
related signaling for the MN that caused the message.
This flag will govern the multicast-related signaling between the LMA
Contreras, et al. Expires November 23, 2012 [Page 8]
Internet-Draft PMIPv6 multicast handover optimization May 2012
and the MAG. As a general rule, the value of the flag in the PBA
message should be a copy of the value received in the PBU message.
Specific rules are described in next sub-sections.
4.2.1.1.1. Registration process
During handover, the entities involved in this process are the nMAG
and the LMA. These rules also apply for the Initial Binding
registration process.
o PBU message
* S=0, it indicates that the MAG sending the PBU message does not
accept multicast-related signaling for the MN being attached.
This can be used to discriminate PMIPv6 nodes which are not
multicast enabled, for backward compatibility reasons.
* S=1, it indicates that the MAG sending the PBU message accepts
multicast-related signaling for the MN being attached.
Depending on the type of handover (reactive or proactive) the
LMA will take some actions, described later in this document.
o PBA message
* If S=0 in the corresponding PBU message, the value of the flag
in the PBA message should be a copy of the value received in
the PBU message (thus S=0), without any further meaning.
* If S=1 in the corresponding PBU message, two sub-cases can
happen
+ S=1 and "Active Multicast Subscription" mobility option in
the PBA message. When the MN maintains an active multicast
session, if the LMA is able to provide the multicast
subscription information during registration, the PBA
message will include the "Active Multicast Subscription"
mobility option with the IP addresses of the subscribed
group and the source providing it. If the LMA is not able
to provide such information during registration, the PBA
message will include the "Active Multicast Subscription"
mobility option with the IP addresses of the group and the
source set to 0. This case is useful to decouple unicast
and multicast signaling for an MN being registered at nMAG.
A way for obtaining later active multicast-subscription
information is described later in this document.
+ S=0 in the PBA message if the MN does not maintain an active
multicast subscription (note that for backward compatibility
Contreras, et al. Expires November 23, 2012 [Page 9]
Internet-Draft PMIPv6 multicast handover optimization May 2012
reasons an LMA not supporting multicast related signaling
would always send S=0).
4.2.1.1.2. De-registration process
During handover, the entities involved in this process are the pMAG
and the LMA. These rules apply for the Binding De-registration
process
o PBU message
* S=0, it indicates that the MN has no active multicast session
(note that for backward compatibility reasons a pMAG not
supporting multicast related signaling would always send S=0).
* S=1, it indicates that the MN has an active multicast session,
and the IP addresses of the subscribed group and the source
providing it are transported in the "Active Multicast
Subscription" mobility option.
o PBA message
* The value of the flag in the PBA message should be 0, without
any further meaning (note that for backward compatibility
reasons an LMA not supporting multicast related signaling would
always send S=0).
4.2.1.2. New format of conventional PBU/PBA messages
4.2.1.2.1. Proxy Binding Update message
As result of the new defined flag, the PBU message results as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contreras, et al. Expires November 23, 2012 [Page 10]
Internet-Draft PMIPv6 multicast handover optimization May 2012
4.2.1.2.2. Proxy Binding Acknowledgement Message
As result of the new defined flag, the PBA message results as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.2. Multicast Active flag in the LMA Binding Cache and (optionally)
on the MN's policy store
4.2.2.1. Flag application rules
A new flag A is added in the LMA Binding Cache to retain the
knowledge that the registered MN maintains or not an active multicast
subscription. The basic use of this flag is to restrict the
interrogation of the pMAG only to the cases in which the MN certainly
is maintaining an active subscription. The algorithm which is
followed by the LMA to interrogate or not the pMAG (after receiving a
PBU message from the nMAG) is as follows:
o Flag S=0 & flag A=0: this situation represents the case where the
nMAG does not support multicast-related signaling for the MN being
registered, and, additionally, the LMA is not aware of any active
multicast subscription on-going. Then, the LMA does not
interrogate the pMAG, and registers the MN as attached to the nMAG
as usual.
o Flag S=0 & flag A=1: this situation represents the case where the
nMAG does not support multicast-related signaling for the MN being
registered, but the LMA is aware of one or more on-going MN's
active multicast subscriptions. Due to the fact that multicast
signaling is not supported by the nMAG for that MN, the LMA does
not interrogate the pMAG, and registers the MN as attached to the
nMAG as usual.
Contreras, et al. Expires November 23, 2012 [Page 11]
Internet-Draft PMIPv6 multicast handover optimization May 2012
o Flag S=1 & flag A=0: this situation represents the case where the
nMAG supports multicast-related signaling for the MN being
registered, but the LMA is not aware of any active multicast
subscription. Then, the LMA does not interrogate the pMAG, and
registers the MN as attached to the nMAG as usual.
o Flag S=1 & flag A=1: this situation represents the case where the
nMAG supports multicast-related signaling for the MN being
registered, and, additionally, the LMA is aware of one or more on-
going MN's active multicast subscriptions. Then, the LMA
interrogates the pMAG to obtain the multicast subscription details
in the form of (S,G) previously to complete the registration of
the MN attached to the nMAG.
The flag A should be initialized to the value 0.
Optionally, this flag can be also added to the MN's policy store, and
dynamically updated by the LMA to signal that the MN has (or not) an
active multicast subscription. By introducing this flag in the MN's
policy profile, the nMAG can know in advance the existence of an
active multicast session by the incoming MN.
4.3. New messages
4.3.1. Messages for active multicast subscription interrogation
A new pair of messages is defined for interrogating entities about
the active multicast subscription of the MN when the handover is of
reactive type.
These messages are sent using the Mobility Header as defined in
[RFC6275].
4.3.1.1. Subscription Query message
4.3.1.1.1. Message application rules
The Subscription Query message is sent by the LMA towards the pMAG to
interrogate it about any existing multicast subscription of the MN
which is being registered by the nMAG. This message is generated in
case that the handover is of reactive type.
Additionally, this message is sent by the nMAG towards the LMA to
interrogate it about the existing multicast subscription of the MN
when the LMA acknowledges the PBU sent by the nMAG but the multicast
information is not provided (in detail, when the PBU messages has set
the flag S to 1, and the PBA message has set the flag S to 1 but the
IP addresses of the group and the source in the "Active Multicast
Contreras, et al. Expires November 23, 2012 [Page 12]
Internet-Draft PMIPv6 multicast handover optimization May 2012
Subscription" mobility option are set to 0).
4.3.1.1.2. Message format
The Subscription Query message has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
The Sequence Number field establishes the order of the messages
sent in the Subscription Query / Subscription Response dialogue
between the LMA and the MAG for a certain MN. The initial
Sequence Number will be determined by the entity which creates the
message (either LMA or MAG, depending on the scenario), which will
be responsible of managing this counter.
Reserved:
This field is unused for now. The value must be initialized to 0.
Mobility options:
This message will carry one or more TLV-encoded mobility options.
The valid mobility options for this message are the following:
* Mobile Node Identifier option (mandatory)
* Home Network Prefix option (optional)
There can be one or more instances of the Home Network Prefix
option, but only one instance of the Mobile Node Identifier
option.
Contreras, et al. Expires November 23, 2012 [Page 13]
Internet-Draft PMIPv6 multicast handover optimization May 2012
4.3.1.2. Subscription Response message
4.3.1.2.1. Message application rules
The Subscription Response message is sent by the pMAG towards the
LMA, or by the LMA towards the nMAG, to answer a previously received
Subscription Query message, as described above.
4.3.1.2.2. Message format
The Subscription Response message has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
The value of the Sequence Number field in the Subscriber Response
message must be a copy of the Sequence Number received in the
Subscription Query message.
Multicast Information (I):
The multicast Information flag I specifies if there is multicast
subscription information available for the MN or not. The meaning
is the following:
I=0: there is no multicast subscription information available
for the MN identified by the Mobile Node Identifier option in
this message.
I=1: there is multicast subscription information available for
the MN identified by the Mobile Node Identifier option in this
message. The multicast subscription information is carried on
one or more instances of the Active Multicast Subscription
option in this message (one instance for each active
subscription).
Reserved:
Contreras, et al. Expires November 23, 2012 [Page 14]
Internet-Draft PMIPv6 multicast handover optimization May 2012
This field is unused for now. The value must be initialized to 0.
Mobility options:
This message will carry one or more TLV-encoded mobility options.
The valid mobility options for this message are the following:
* Mobile Node Identifier option (mandatory)
* Active Multicast Subscription option (mandatory) only when flag
I=1, not present in any other case
* Home Network Prefix option (optional)
There can be one or more instances of the Home Network Prefix
option (in all cases) and the Active Multicast Subscription option
(only when I=1), but only one instance of the Mobile Node
Identifier option.
4.3.2. Messages for active multicast subscription indication
A new pair of messages is defined for setting up and down the
optional A flag defined above.
These messages are sent using the Mobility Header as defined in
[RFC6275].
4.3.2.1. Multicast Activity Indication message
4.3.2.1.1. Message application rules
The Multicast Activity Indication message is sent by a MAG towards
the LMA to set to 1 or 0 the A flag either to indicate the start or
the complete cease of any multicast subscription by the MN. Through
the use of this message, the LMA becomes aware that one or more
multicast flows are being forwarded to a MN. This information is
useful for the LMA during a handover to discriminate if the pMAG
should be asked or not about multicast information corresponding to
the MN being registered at the nMAG, in case that the handover is of
reactive type.
4.3.2.1.2. Message format
The Multicast Activity Indication message has the following format.
Contreras, et al. Expires November 23, 2012 [Page 15]
Internet-Draft PMIPv6 multicast handover optimization May 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
The Sequence Number field establishes the order of the messages
sent in the Activity Indication / Activity Indication Ack dialogue
between the MAG and the LMA for a certain MN. The initial
Sequence Number will be determined by the MAG, which will be
responsible of managing this counter.
Activity indicator (A):
The Activity indicator flag A specifies if the MN multicast
activity is on, that is, if the MN maintains one or more active
multicast subscriptions at the MAG. The meaning is the following:
A=0: the multicast activity of the MN (identified by the Mobile
Node Identifier option in this message) is off.
A=1: the multicast activity of the MN (identified by the Mobile
Node Identifier option in this message) is on.
Reserved:
This field is unused for now. The value must be initialized to 0.
Mobility options:
This message will carry one or more TLV-encoded mobility options.
The valid mobility options for this message are the following:
* Mobile Node Identifier option (mandatory)
* Home Network Prefix option (optional)
There can be one or more instances of the Home Network Prefix
option, but only one instance of the Mobile Node Identifier
option.
Contreras, et al. Expires November 23, 2012 [Page 16]
Internet-Draft PMIPv6 multicast handover optimization May 2012
4.3.2.2. Multicast Activity Indication Acknowledge message
4.3.2.2.1. Message application rules
The Multicast Activity Indication Acknowledge message is sent by the
LMA towards a MAG to confirm the reception of a previously sent
Multicast Activity Indication message.
4.3.2.2.2. Message format
The Multicast Activity Indication message has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
The value of the Sequence Number field in the Activity Indication
Ack message must be a copy of the Sequence Number received in the
Activity Indication message.
Reserved:
This field is unused for now. The value must be initialized to 0.
Mobility options:
This message will carry one or more TLV-encoded mobility options.
The valid mobility options for this message are the following:
* Mobile Node Identifier option (mandatory)
* Home Network Prefix option (optional)
There can be one or more instances of the Home Network Prefix
option, but only one instance of the Mobile Node Identifier
option.
Contreras, et al. Expires November 23, 2012 [Page 17]
Internet-Draft PMIPv6 multicast handover optimization May 2012
4.4. New PBA timer in the LMA
A new timer named "PBA timer" is used in the LMA to define the
maximum waiting time before the PBA message is sent to the nMAG in
case the multicast subscription information relative to the MN is not
yet available. The aim of this timer is to prevent potential large
delays in the forwarding of unicast traffic towards the MN being
registered at the nMAG. This timer allows decoupling the unicast
signaling from the multicast one.
This timer should be upper bounded by the constant defined in
[RFC6275] INIT_BINDACK_TIMEOUT, whose default value is 1 s. This
constant sets the time when the nMAG will retry the MN registration
by sending again the PBU message. The "PBA timer" has to ensure that
the nMAG does not enter the retry mode.
5. Signaling processes description
A number of new signaling processes are introduced with this
solution. Next sections describe these new processes in detail.
5.1. Multicast Activity signaling
This solution makes use of the flag A to keep track of existing
multicast activity in a certain MN. The idea behind this is to
define a mechanism which helps the LMA to decide whether to
interrogate or not the pMAG about potential subscription information.
5.1.1. Multicast Activity set to ON (A=1)
Figure 1 summarizes this process.
Contreras, et al. Expires November 23, 2012 [Page 18]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+-----+ +-----+ +-----+
| MN1 | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
1) | |==Bi-Dir Tunnel=|
| | |
| unicast data | |
|<-v-v-v-v-v-v-v-| |
| | |
| MLD Rep(S,G) | |
|--------------->| Act Ind(start) |
2) | |--------------->|
| (S,G) Data | (flag A = 1)
|<---------------| Act Ind Ack |
| |<---------------|
| | |
Figure 1: Multicast Activity set to ON
The sequence of messages is the following:
1. An MN, named MN1, is attached to the MAG. The MN is a multicast-
enabled node, and it is only receiving unicast traffic as usual
in PMIPv6 domains, with no multicast subscription yet. At some
point in time, the MN1 requests to the MAG to be subscribed to
the content identified by the IP addresses (S,G), by sending a
standard MLD report from the MN to the MAG. The MAG will keep
the multicast status state of the point-to-point link with the
MN. In case the MAG has not already subscribed to the multicast
flow (S,G) it joins the content on behalf of MN. Multicast flow
(S,G) is subsequently forwarded by the MAG to the MN1.
2. Due to this initial multicast subscription for the MN1, the MAG
triggers the multicast Activity Indication message towards the
LMA, to indicate that the MN1 multicast activity is ON. The LMA
will set the flag A to 1. Afterwards, the LMA sends an Activity
Indication Ack message to the MAG to acknowledge the previous
indication.
5.1.2. Multicast Activity set to OFF (A=0)
Figure 2 presents the corresponding flow.
Contreras, et al. Expires November 23, 2012 [Page 19]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+-----+ +-----+ +-----+
| MN1 | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
| MLD Done(S,G) | |
1) |---------------->X stops fwrding |
| | |
| | Act Ind(stop) |
2) | |--------------->|
| | (flag A = 0)
| | Act Ind Ack |
| |<---------------|
| | |
Figure 2: Multicast Activity set to OFF
The message flow is as follows:
1. Some time later, the MN1 decides to totally stop all the active
multicast subscriptions that it maintains. The MN1 will send an
MLD Done message to the MAG to request the cease of the multicast
traffic delivery. As a consequence, the MAG will stop all the
multicast traffic forwarding to the MN1.
2. After removing the active subscriptions for the MN1, the MAG
sends a multicast Activity Indication message to the LMA
indicating that the MN1 multicast activity is OFF. The LMA will
set the flag A to 0, its default value. Afterwards, the LMA
sends an Activity Indication Ack message to the MAG to
acknowledge the previous indication.
5.2. Handover signaling procedures
As the MN moves from one access gateway (named previous-MAG, pMAG) to
another (named new-MAG, nMAG), the mobility-related signaling due to
the handover event is carried out independently by the pMAG and the
nMAG. That signaling process is not synchronized and, thus, two
scenarios should be considered depending on the order in which the
LMA receives notification of the MN registration and de-registration
in the nMAG and the pMAG respectively.
5.2.1. Handover of proactive type
5.2.1.1. Rationale
In the proactive case, the LMA receives the MN de-registration from
the pMAG previously to receive the MN registration from the nMAG.
Contreras, et al. Expires November 23, 2012 [Page 20]
Internet-Draft PMIPv6 multicast handover optimization May 2012
Only for those MNs which maintain an active multicast subscription,
the pMAG will include, as part of the PBU message (with flag S set to
1), the new TLV-encoded mobility option "Active Multicast
Subscription" carrying the IP addresses of the multicast
subscription(s) active in the MN at that moment.
The LMA will store that information in the corresponding binding
cache. If, later on, the MN attaches to a nMAG, this information
will be sent (using the same TLV option) to the nMAG as part of the
PBA confirmation of the registration process (the PBU message sent by
the nMAG should set the flag S to 1). On the other hand, if no
further registration happens, the multicast information will be
removed together with the rest of binding database for that MN.
After receiving the multicast addresses of the group(s) subscribed to
by the MN, and of the source(s) delivering the corresponding
multicast content, the nMAG can subscribe to the multicast flow(s) on
behalf of the MN if there is no other MN receiving it already at the
nMAG. The multicast status can be also set in advance for the point-
to-point link towards the MN.
5.2.1.2. Message flow description
Figure 3 summarizes this process.
Contreras, et al. Expires November 23, 2012 [Page 21]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| |==Bi-Dir Tunnel=| |
| Multicast Data | | |
|<---------------| | |
| | | |
1) MN Detached | | |
| MN Detached Event | |
| | | |
| |Ext'd DeReg PBU | |
2) | |--------------->| |
| | | |
3) | | Accept PBU |
| |(Multicast Subscription info stored)
| | | |
| | PBA | |
4) | |<---------------| |
| | | |
5) MN Attached | | |
| | | MN Attached Event
| | | |
| | | PBU |
6) | | |<---------------|
| | | |
| | | Ext'd PBA |
7) | | |--------------->|
| | | |
8) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Multicast Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 3: Proactive handover
The message flow is as follows:
1. A registered MN is receiving a multicast content which has been
previously subscribed to by sending a standard MLD report from
the MN to the currently serving MAG, pMAG. The pMAG keeps the
multicast status state of the point-to-point link with the MN.
Contreras, et al. Expires November 23, 2012 [Page 22]
Internet-Draft PMIPv6 multicast handover optimization May 2012
2. The MN perceives a better radio link and decides to initiate a
handover process over a radio access controlled by a new MAG,
nMAG. As a consequence, pMAG determines a detach event
corresponding to this MN, and updates the attachment status of
this MN to the LMA by sending an extended Proxy Binding Update
message, including a new TLV-encoded option, named "Active
Multicast Subscription", which contains the IP addresses of the
(S,G) pairs of the active multicast subscriptions in the moment
of handover.
3. The LMA processes the PBU message. Additionally, the LMA stores
in the Binding Cache the information regarding the on-going
multicast subscription(s) when the detachment is initiated. This
information will be kept until a new registration of the MN is
completed by another MAG, or till the Binding Cache expiration,
according to [RFC5213].
4. The LMA acknowledges to the pMAG the previous PBU message.
5. As a result of the handover process, the MN attaches to another
MAG, called nMAG.
6. The nMAG triggers a registration process by sending a PBU message
(with flag S set to 1) to the LMA.
7. After the analysis of the PBU message, the LMA sends an extended
PBA including the new "Active Multicast Subscription" option,
which contains the IP addresses of the (S,G) pairs of the active
multicast subscriptions in the moment of handover.
8. The nMAG processes the PBA message following all the standard
procedures described in [RFC5213]. Additionally, with the new
information relative to multicast subscription, the nMAG will set
up the multicast status of the point-to-point link between the
nMAG and the MN, and will join the content identified by (S,G) on
behalf of the MN in case the nMAG is not receiving already such
content due to a previous subscription ordered by another MN
attached to it. From that instant, the multicast content is
served to the MN.
5.2.2. Handover of reactive type
5.2.2.1. Rationale
In the reactive case, the LMA receives the MN registration from the
nMAG without having previously received the MN de-registration from
the pMAG.
Contreras, et al. Expires November 23, 2012 [Page 23]
Internet-Draft PMIPv6 multicast handover optimization May 2012
As the nMAG is not aware of any active multicast subscription of the
MN, the nMAG will start a conventional registration process, by
sending a normal PBU message (with flag S set to 1) towards the LMA.
After receiving the PBU message from the nMAG, the LMA will take the
decision of interrogating or not the pMAG regarding any existing
multicast subscription for that MN. This decision is taken following
a procedure that is described later.
Once the multicast subscription information is retrieved from the
pMAG, the LMA encapsulates it in the PBA message by using the TLV
option "Active Multicast Subscription", and forwards the PBA message
to the nMAG. Then, the nMAG can subscribe the multicast flow on
behalf of the MN, if there is no other MN receiving it already at the
nMAG. The multicast status can be also set in advance for the point-
to-point link towards the MN.
5.2.2.2. Message flow description
Figure 4 summarizes this process.
Contreras, et al. Expires November 23, 2012 [Page 24]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+-----+ +-----+ +----+ +-----+ +----+
| MN1 | | MN2 | |pMAG| | LMA | |nMAG|
+-----+ +-----+ +----+ +-----+ +----+
| | | | |
| | | | MN1 Attached Event
| | | | |
| | | | PBU |
1) | | | |<---------------|
| | | LMA decision |
| | | | |
| | | Subscr Query | |
2) | | |<---------------| |
| | | | |
| | | Subscr Resp | |
3) | | |--------------->| |
| | | | |
| | | (Multicast Subscription |
| | | info forwarding) |
| | | | |
| | | | Ext'd PBA |
4) | | | |--------------->|
| | | | |
5) | | | | Accept PBA,
| | | | Multicast Group join
| | | | and P-t-P status setup
| | | | |
| | | |==Bi-Dir Tunnel=|
| | | | |
| | | | (S,G) Data |
|<-------------------------------------------------|
| | | | |
| | | | MN2 Attached Event
| | | | |
| | | | PBU |
6) | | | |<---------------|
| | | LMA decision |
| | | | PBA |
7) | | | |--------------->|
| | | | |
8) | | | | Accept PBA
| | | | |
Figure 4: Reactive handover
Consider as starting point the situation where a couple of MNs, named
MN1 and MN2, are attached to the pMAG, both MNs being multicast-
enabled nodes, but only MN1 maintains an active multicast
subscription at this moment. As consequence, the value of the A flag
Contreras, et al. Expires November 23, 2012 [Page 25]
Internet-Draft PMIPv6 multicast handover optimization May 2012
in the LMA is set to 1 for MN1, and set to 0 for MN2.
The sequence of messages for the handover of MN1 and MN2 is the
following (as depicted in Figure 4):
1. At certain time, the MN1 perceives a better radio link and
decides to attach at a new MAG, nMAG, in a handover process (as
it is a reactive case, the pMAG is not aware of the detachment
process). Then, the nMAG triggers a registration process by
sending a PBU message (with flag S set to 1) to the LMA.
2. Prior to acknowledge the received PBU message, the LMA checks the
status of the A flag for this MN. Due that the flag A=1, the LMA
interrogates the pMAG about if there is any active multicast
subscription for the MN1, by sending a Subscription Query
message.
3. The pMAG answers the LMA with a Subscription Response message
including the IP addresses of the existing subscriptions (the
pair (S,G) in this case).
4. After processing the pMAG answer, the LMA acknowledges (with flag
S set to 1) the PBU message, including the multicast subscription
information within the new TLV-encoded option "Active Multicast
Subscription". The nMAG then process the extended PBA message.
5. The nMAG processes the PBA message, and it proceeds to set up the
multicast status of the point-to-point link between the nMAG and
the MN1, and to join the content identified by (S,G) on behalf of
the MN1 in case the nMAG is not receiving already such content.
(The bidirectional tunnel is also set up between the nMAG and the
LMA if it has not been established before by another MN
connection). At this moment, the multicast content can be served
to the MN1. The unicast traffic for the MN1 can be forwarded as
well.
6. In parallel, the MN2 perceives a better radio link and decides to
attach also to the nMAG in a reactive handover process as well
(the pMAG is not aware of this detachment process either). Then,
the nMAG triggers a registration process by sending a PBU message
(with flag S set to 1) to the LMA.
7. Prior to acknowledge the received PBU message, the LMA checks the
status of the A flag for this MN. Due that the flag A=0, the LMA
does not interrogate the pMAG, and acknowledges the PBU message
(with flag S set to 0). The nMAG then processes PBA message.
Contreras, et al. Expires November 23, 2012 [Page 26]
Internet-Draft PMIPv6 multicast handover optimization May 2012
8. The nMAG is now ready to forward the unicast traffic to the MN2.
5.2.2.3. Further considerations for the reactive handover signaling
A handover event is managed independently by the pMAG and nMAG. It
is not a synchronized process. In a reactive handover, the LMA will
receive a registration PBU from nMAG before a de-registration PBU
from pMAG, if any.
In the message flows detailed above, it could be the case that the
LMA receives a de-registration PBU from pMAG just after sending the
Subscription Query message, but before receiving the Subscription
Response message. That de-registration PBU message from pMAG will
carry the multicast subscription information required to assist the
MN in the handover, so such valuable information should be kept by
the LMA. Furthermore, it is possible that once the Subscription
Query message arrives to pMAG, the pMAG could have already removed
the multicast related information for the MN.
In order to avoid losing the multicast subscription information sent
in the de-registration PBU message, the LMA should store it, and
include it in the PBA message towards the nMAG in case the
Subscription Response message from the pMAG does not contain
multicast subscription information for the MN.
5.2.3. LMA decision process
A key point of the solution proposed in this document resides on the
LMA decision of interrogating the pMAG about a potential active
subscription of the MN entering the nMAG. Several variables take
place, and it is required to define a mechanism for assisting the LMA
in its decision process.
Basically two flags will be used. One flag, the named "multicast
Signaling" or S flag, is used to signal the multicast capabilities of
the MAGs and the transport of the multicast subscription information
within the PBU/PBA messages. The other one, the named "multicast
Activity" or A flag, is used to register on the LMA whether the MN is
maintaining an active multicast subscription or not.
The following sections summarize the use of these flags on the LMA
decision process.
5.2.3.1. LMA processing of S flag on reception of PBU messages
Contreras, et al. Expires November 23, 2012 [Page 27]
Internet-Draft PMIPv6 multicast handover optimization May 2012
5.2.3.1.1. Proactive handover
In the event of proactive handover, the pMAG has previously informed
the LMA about any potential subscription information currently active
in the MN. The actions to be carried out by the LMA once it receives
the PBU message from the nMAG are summarized in the table below.
+---------+---------+------------------------+----------------------+
|multicast|multicast| | |
|signaling|activity | Meaning | LMA action |
| flag S | flag A | | |
+---------+---------+------------------------+----------------------+
| | |- Multicast not | |
| | A=0 | supported by nMAG |- MN registration as |
| | |- No active subscription| in RFC 5213 |
| | | by MN | (S=0 in PBA) |
| S=0 +---------+------------------------+----------------------+
| | |- Multicast not |- LMA stores multicast|
| | A=1 | supported by nMAG | subscription info |
| | |- Active subscription |- MN registration as |
| | | by MN | in RFC 5213 |
| | | | (S=0 in PBA) |
+---------+---------+------------------------+----------------------+
| | |- Multicast supported by| |
| | A=0 | nMAG |- MN registration as |
| | |- No active subscription| in RFC 5213 |
| | | by MN | (S=0 in PBA) |
| S=1 +---------+------------------------+----------------------+
| | | |- LMA stores multicast|
| | |- Multicast supported by| subscription info |
| | A=1 | nMAG |- MN registration |
| | |- Active subscription | conveys multicast |
| | | by MN | subscription info |
| | | | (S=1 in PBA) |
+---------+---------+------------------------+----------------------+
Figure 5
5.2.3.1.2. Reactive handover
In the event of reactive handover, the LMA is not aware about any
potential subscription information currently active in the MN. The
actions to be carried out by the LMA once it receives the PBU message
from the nMAG are summarized in the table below.
Contreras, et al. Expires November 23, 2012 [Page 28]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+---------+---------+-------------------------+---------------------+
|multicast|multicast| | |
|signaling|activity | Meaning | LMA action |
| flag S | flag A | | |
+---------+---------+-------------------------+---------------------+
| | |- Multicast not supported| |
| | A=0 | by nMAG |- MN registration as |
| | |- No active subscription | in RFC 5213 |
| | | by MN | (S=0 in PBA) |
| S=0 +---------+-------------------------+---------------------+
| | |- Multicast not supported|- LMA does not |
| | A=1 | by nMAG | interrogate pMAG |
| | |- Active subscription |- MN registration as |
| | | by MN | in RFC 5213 |
| | | | (S=0 in PBA) |
+---------+---------+-------------------------+---------------------+
| | |- Multicast supported by |- LMA does not |
| | A=0 | nMAG | interrogate pMAG |
| | |- No active subscription |- MN registration as |
| | | by MN | in RFC 5213 |
| | | | (S=0 in PBA) |
| +---------+-------------------------+---------------------+
| | | |- LMA interrogates |
| S=1 | | | pMAG to obtain |
| | |- Multicast supported by | multicast |
| | A=1 | nMAG | subscription |
| | |- Active subscription |- MN registration |
| | | by MN | conveys multicast |
| | | | subscription info |
| | | | (S=1 in PBA) |
+---------+---------+-------------------------+---------------------+
Figure 6
5.2.3.2. LMA set-up of S flag in PBA messages
Once the LMA decision process is finished, the LMA builds the PBA
message to complete the registration process triggered by the nMAG.
The value of the S flag in the PBA message will be set according to
the data specified in the table below.
Contreras, et al. Expires November 23, 2012 [Page 29]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+---------------+-------------+-------------------------------+
| S flag | S flag | |
| received in | sent in | Meaning |
| PBU message | PBA message | |
+---------------+-------------+-------------------------------+
| | | |
| S=0 | S=0 | No further meaning |
| | | |
| (multicast +-------------+-------------------------------+
| not supported | | |
| by nMAG) | S=1 | N/A |
| | | |
+-------------- +-------------+-------------------------------+
| | | |
| | S=0 | No active subscription on MN |
| | | |
| +-------------+-------------------------------+
| S=1 | | - (S,G) info available: |
| (multicast is | | Multicast subscription info |
| supported by | | is conveyed in the PBA |
| nMAG) | | message |
| | S=1 | - (S,G) info not available: |
| | | (IP addresses set to 0) |
| | | It has to be requested by |
| | | using the Subscription Query|
| | | message. |
+---------------+-------------+-------------------------------+
Figure 7
5.2.4. Prevention of large delays of the binding acknowledgement for
unicast traffic
According to the message sequences described for the reactive
handover case, in case the LMA has to request the multicast
subscription information from the pMAG, the binding request sent by
the nMAG is maintained on-hold till the LMA receives, processes and
includes the multicast subscription information into the extended PBA
message. As consequence, the unicast traffic may then suffer an
extra delay motivated by the multicast-related signaling. During
that time, the unicast traffic with destination the MN being
registered by the nMAG must be buffered or discarded by the LMA.
In order to avoid any potential large delay in the forwarding of
unicast traffic arriving at the LMA towards the MN, a mechanism
should be implemented to decouple multicast from unicast traffic
reception by the MN.
Contreras, et al. Expires November 23, 2012 [Page 30]
Internet-Draft PMIPv6 multicast handover optimization May 2012
Figure 8 shows this mechanism:
Contreras, et al. Expires November 23, 2012 [Page 31]
Internet-Draft PMIPv6 multicast handover optimization May 2012
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
1) | |==Bi-Dir Tunnel=| |
| unicast data | | |
|<-v-v-v-v-v-v-v-| | |
| | | |
| Multicast Data | | |
|<---------------| | |
| | | MN1 Attached Event
| | | PBU |
2) | | |<---------------|
| | Subscr Query | |
3) | |<---------------| |
| | | |
4) | | <PBA timer starts> |
| | /// |
| | /// |
5) | | <PBA timer expires> |
| | | |
| | | Ext'd PBA |
| | |--------------->|
| | | |
| | | Accept PBA
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Unicast Data |
|<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-|
| | | |
| | | Subscr Query |
6) | | |<---------------|
| | Subscr Resp | |
7) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Subscr Resp |
8) | | |--------------->|
| | | |
| | | Multicast Group join
| | | and P-t-P status setup
| | Multicast Data | |
|<-------------------------------------------------|
| | | |
Figure 8: Decoupling of unicast and multicast signaling
Contreras, et al. Expires November 23, 2012 [Page 32]
Internet-Draft PMIPv6 multicast handover optimization May 2012
The sequence of messages is the following:
1. An MN is attached to the pMAG. The MN is a multicast-enabled
node, and it is receiving both unicast and multicast traffic
simultaneously.
2. Some time later, the MN perceives a better radio link and decides
to attach at a new MAG, nMAG, in a handover process (as a
reactive case, the pMAG is not aware of the detachment process).
Then, the nMAG triggers a registration process by sending a PBU
message (with flag S set to 1) to the LMA.
3. Prior to acknowledge the received PBU message, the LMA decides to
interrogate the pMAG about if there is any active multicast
subscription for the MN, by sending a Subscription Query message.
The LMA decision is based on the checking of flag A when the
reactive handover manages the multicast activity indication.
4. Immediately after sending the Subscription Query message, the LMA
starts the timer "PBA timer", which determines the maximum
waiting time before the PBA is sent to avoid any potential large
delay in the forwarding of unicast traffic towards the MN.
5. In case the "PBA timer" expires, the LMA acknowledges the PBU
message, by sending the PBA message with flag S=1, and the
"Active Multicast Subscription" mobility option with the (S,G) IP
addresses set to 0. The nMAG then processes the extended PBA
message. Such acknowledgement will allow the MN to receive the
unicast traffic from that time on. (The bidirectional tunnel is
also set up between the nMAG and the LMA if it has not been
established before).
6. In parallel, the nMAG sends a Subscription Query message to the
LMA requesting the multicast-subscription details yet unknown for
the MN.
7. The pMAG answers the Subscription Query message originally sent
by the LMA, including the IP addresses of the existing
subscriptions (the pair (S,G) in this case).
8. After processing the pMAG answer, the LMA sends a Subscription
Response message to the nMAG, including the multicast
subscription information within the new TLV-encoded option
"Active Multicast Subscription". The nMAG processes the PBA
message, and it proceeds to set up the multicast status of the
point-to-point link between the nMAG and the MN, and to join the
content identified by (S,G) on behalf of the MN in case the nMAG
is not receiving already such content. (The bidirectional tunnel
Contreras, et al. Expires November 23, 2012 [Page 33]
Internet-Draft PMIPv6 multicast handover optimization May 2012
is also set up between the nMAG and the LMA if it has not been
established before). At this moment, the multicast content can
also be served to the MN.
6. Co-existence with PMIPv6 multicast architectural evolutions
Along this document, it has been considered that the LMA entity is in
charge of delivering both unicast and multicast traffic to a certain
MN through the bi-directional tunnels connecting to the MAG where the
MN is attached, as specified in the base solution defined in
[RFC6224]. However, the solution described in this memo is not only
applicable to the base solution, but also it can be applied to other
solutions envisioned as possible architectural evolutions to solve
the tunnel convergence problem affecting the base solution, as those
stated in [I-D.ietf-multimob-pmipv6-ropt].
The Multicast Tree Mobility Anchor (MTMA) solution in
[I-D.ietf-multimob-pmipv6-ropt] makes use of a separate entity to
serve multicast traffic through distinct tunnels connected to the
MAGs. The tunnels for multicast traffic could not be set up in
advance if they are dynamical in nature.
When the "multicast activity" flag is also present in the MN's policy
store, the nMAG knows in advance the multicast activity of the
incoming MN. Consequently, the nMAG can trigger the multicast tunnel
set up in parallel to the registration process, including the
acquisition of the active multicast subscription details (the IP
addresses of the source and the content), saving time on serving the
multicast flow to the incoming MN. The concrete procedure for
multicast tunnel establishment is out of the scope of this document.
7. Benefits of layer-2 triggers for fast handover
As stated before, the global performance of the multicast handover
can be improved in the case that layer-2 triggers are supported by
the underlying radio technology. In [RFC5949], a procedure which
allows to buffer at the pMAG and forward to the nMAG the traffic with
destination the MN during the handover duration is defined. This
forwarding can be beneficial for either strict real-time services or
for networks with long handover duration. By forwarding the traffic
to the MN, the disruption of the multicast traffic reception is
minimized.
The solution in [RFC5949] avoids packet loss during the handover.
Even so, using the proposal in this memo is still useful, because
reducing the time required to set up multicast traffic delivery in
Contreras, et al. Expires November 23, 2012 [Page 34]
Internet-Draft PMIPv6 multicast handover optimization May 2012
the nMAG minimizes the buffering needed at the pMAG.
In any case, because the feature in [RFC5949] is dependent on the
capabilities of both the underlying radio technology and the layer-2
triggering functionalities supported by the MN, and that not all the
multicast applications could take benefit of it, that functionality
could be seen as optional for multicast handover optimization.
8. Security Considerations
TBD.
9. IANA Considerations
This document defines the new following elements which values should
be allocated:
o Mobility Header types: the Subscription Query and Subscription
Response, and the Multicast Activity Indication and Multicast
Activity Indication Acknowledge mobility header types.
o Mobility options: the Active Multicast Subscription mobility
option.
o Flags: the multicast Signaling (S), the multicast Information (I),
and the multicast Active (A) flags.
10. Contributors
Dirk Von Hugo (Telekom Innovation Laboratories,
Dirk.von-Hugo@telekom.de) has largely contributed to this document.
11. Acknowledgments
The authors would like to thank (in alphabetical order) Hitoshi
Asaeda, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt and Stig
Venaas for their valuable comments and discussions on the Multimob
mailing list. The authors are also grateful with Hitoshi Asaeda and
Behcet Sarikaya for their review of this document.
The research of Carlos J. Bernardos leading to these results has
received funding from the European Community's Seventh Framework
Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL
project), being also partially supported by the Ministry of Science
Contreras, et al. Expires November 23, 2012 [Page 35]
Internet-Draft PMIPv6 multicast handover optimization May 2012
and Innovation (MICINN) of Spain under the QUARTET project (TIN2009-
13992-C02-01).
The research of Ignacio Soto has also received funding from the
Spanish MICINN through the I-MOVING project (TEC2010-18907).
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
12.2. Informative References
[I-D.ietf-multimob-pmipv6-ropt]
Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y.
Kim, "Multicast Mobility Routing Optimizations for Proxy
Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-00 (work in
progress), March 2012.
[I-D.von-hugo-multimob-future-work]
Hugo, D., Asaeda, H., Sarikaya, B., and P. Seite,
"Evaluation of further issues on Multicast Mobility:
Potential future work for WG MultiMob",
draft-von-hugo-multimob-future-work-02 (work in progress),
June 2010.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
Contreras, et al. Expires November 23, 2012 [Page 36]
Internet-Draft PMIPv6 multicast handover optimization May 2012
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of
the Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) for Routers in Mobile
and Wireless Networks", RFC 6636, May 2012.
Authors' Addresses
Luis M. Contreras
Telefonica I+D
Don Ramon de la Cruz, 82-84
Madrid 28006
Spain
Email: lmcm@tid.es
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Ignacio Soto
Universidad Politecnica de Madrid
Email: isoto@dit.upm.es
Contreras, et al. Expires November 23, 2012 [Page 37]