Skip to main content

Rapid acquisition of the MN multicast subscription after handover
draft-contreras-multimob-rams-03

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 2011-10-31 (Latest revision 2011-10-30)
Replaced by draft-ietf-multimob-fast-handover
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-contreras-multimob-rams-03
MULTIMOB Working Group                                 Luis M. Contreras
INTERNET-DRAFT                                            Telefonica I+D
Intended Status: Experimental                        Carlos J. Bernardos
Expires: May 3, 2012                    Universidad Carlos III de Madrid
                                                            Ignacio Soto
                                       Universidad Politecnica de Madrid
                                                        October 31, 2011

   Rapid acquisition of the MN multicast subscription after handover
                 <draft-contreras-multimob-rams-03.txt>

Abstract

   A new proposal is presented for speeding up the acquisition by the
   MAG of the MN's active multicast subscription information, in order
   to accelerate the multicast delivery to the MN after a handover. To
   do that, an extension to the current PMIPv6 protocol is proposed. The
   solution described in this memo is not only applicable to the base
   solution for multicast support in PMIPv6, but also it can be applied
   to other solutions envisioned as possible architectural evolutions of
   it. Furthermore, it is also independent of the role played by the MAG
   within the multicast network (either acting as MLD proxy or multicast
   router).

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice
 

Contreras et al.          Expires May 3, 2012                   [Page 1]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   Copyright (c) 2011 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Conventions and Terminology . . . . . . . . . . . . . . . .  5
   2  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3  PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1  New "Active Multicast Subscription" mobility option . . . .  7
       3.1.1  Option application rules  . . . . . . . . . . . . . . .  7
       3.1.2  Option format . . . . . . . . . . . . . . . . . . . . .  7
     3.2  New "multicast Signaling" flag on PBU/PBA message headers .  8
       3.2.1  Flag application rules  . . . . . . . . . . . . . . . .  8
         3.2.1.1  Registration process  . . . . . . . . . . . . . . .  8
         3.2.1.2  De-registration process . . . . . . . . . . . . . .  9
       3.2.2  New format of conventional PBU/PBA messages . . . . . .  9
         3.2.2.1  Proxy Binding Update Message  . . . . . . . . . . .  9
         3.2.2.2  Proxy Binding Acknowledgement Message . . . . . . . 10
       3.3.1  Flag application rules  . . . . . . . . . . . . . . . . 10
     3.4  New messages for active multicast subscription 
          interrogation . . . . . . . . . . . . . . . . . . . . . . . 11
       3.4.1  Subscription Query message  . . . . . . . . . . . . . . 11
         3.4.1.1  Message application rules . . . . . . . . . . . . . 11
         3.4.1.2  Message format  . . . . . . . . . . . . . . . . . . 11
       3.4.2  Subscription Response message . . . . . . . . . . . . . 12
         3.4.2.1  Message application rules . . . . . . . . . . . . . 12
         3.4.2.2  Message format  . . . . . . . . . . . . . . . . . . 13
     3.5  New messages for active multicast subscription indication . 14
       3.5.1  Multicast Activity Indication message . . . . . . . . . 14
         3.5.1.1  Message application rules . . . . . . . . . . . . . 14
         3.5.1.2  Message format  . . . . . . . . . . . . . . . . . . 14
       3.5.2  Multicast Activity Indication Acknowledge message . . . 15
         3.5.2.1  Message application rules . . . . . . . . . . . . . 15
         3.5.2.2  Message format  . . . . . . . . . . . . . . . . . . 15
     3.6  New "PBA timer" in the LMA  . . . . . . . . . . . . . . . . 16
   4  Signaling process description . . . . . . . . . . . . . . . . . 17
 

Contreras et al.          Expires May 3, 2012                   [Page 2]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

     4.1  Handover of proactive type  . . . . . . . . . . . . . . . . 17
       4.1.1  Rationale . . . . . . . . . . . . . . . . . . . . . . . 17
       4.1.2  Message flow description  . . . . . . . . . . . . . . . 17
     4.2  Handover of reactive type . . . . . . . . . . . . . . . . . 19
       4.2.1  Rationale . . . . . . . . . . . . . . . . . . . . . . . 19
       4.2.2  Message flow description  . . . . . . . . . . . . . . . 20
       4.2.3  Further considerations for the reactive handover 
              signaling . . . . . . . . . . . . . . . . . . . . . . . 25
   5  Co-existence with PMIPv6 multicast architectural evolutions . . 29
   6  Benefits of layer-2 triggers for fast handover  . . . . . . . . 29
   7  Security Considerations . . . . . . . . . . . . . . . . . . . . 30
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 30
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     9.1  Normative References  . . . . . . . . . . . . . . . . . . . 30
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 30
   10  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

 

Contreras et al.          Expires May 3, 2012                   [Page 3]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

1  Introduction

   Recently, a base solution has been adopted for continuous multicast
   service delivery in PMIPv6 domains [4]. This solution specifies the
   basic functionality needed in the PMIPv6 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 MN. Thus, once the MN
   attaches to a new MAG, the MN is interrogated by the MAG through an
   MLD General Query, which is sent just after any new link is set up,
   to get knowledge of any existing subscription, as specified in [2].

   However, as highlighted by [5], the base solution must be improved to
   cover some performance requirements, especially those referred to the
   user perceived service quality, seriously affected by the disruption
   of multicast content forwarding to the MN during handovers.

   One MN with an active multicast subscription, moving from one point-
   of attachment to another within a PMIPv6 domain, will experience a
   certain delay in receiving again the multicast content that it was
   previously receiving at the previous location. Such delay will cause
   a gap on the content reception. Two measures can help to mitigate
   such reception gap. One of them is to buffer at the previous MAG the
   traffic with destination the MN and forwarding it at the new MAG, in
   order to properly deliver that traffic to the MN. The other possible
   measure is to reduce the time needed by the new MAG to get knowledge
   of the active multicast subscription maintained by the MN, in order
   to subscribe to the multicast group on behalf of the MN as soon as
   possible.

   While the first measure can be accomplished by using [7] or some
   evolution of it (despite being only applicable in the case the
   underlying radio access technology supports layer-2 triggers), there
   is no a generic standard solution for the rapid acquisition of the
   on-going multicast subscription of the MN.

   The method used in the base solution to get knowledge of an existing
   multicast subscription relies on the behaviour of the IGMP/MLD
   protocols. Both protocols send multicast membership interrogation
   messages when a new link is up. The answer to that request will
   report any existing multicast subscription by the MN.

   Due to this behavior, despite of being a straightforward method, the
   MAG can incur in a huge delay in receiving the corresponding MLD
   Report message caused by either the MLD query processing time or the
   radio transfer delays associated with this procedure.

   The new approach proposed here consists on extending the PMIPv6
 

Contreras et al.          Expires May 3, 2012                   [Page 4]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   signaling protocol defined in [1] by including a new multicast
   information option to update PMIPv6 entities during registration and
   de-registration processes, and new messages to trigger the transfer
   of such multicast information. No extension is required for any of
   the multicast-related protocols (IGMP/MLD or PIM protocols).

   This proposal intends to provide a signaling method internal to the
   network to speed up the subscription information acquisition by the
   MAG, in order to accelerate the multicast delivery to the MN. By
   doing so, the knowledge by the MAG of the currently active multicast
   subscription becomes independent of the underlying radio technology
   dynamics and relaxes the requirement of a rapid response from the MN
   in processing MLD control messages. Issues like radio framing, radio
   access contention, channel reliability, IGMP/MLD timers optimisation
   for wireless environments, etc, are not relevant any more to
   determine multicast performance after handovers.

   The solution described in this memo is not only applicable to the
   base solution defined in [4], but also it can be applied to other
   solutions envisioned as possible architectural evolutions of it, as
   those stated in [6]. Furthermore, it is also independent of the role
   played by the MAG within the multicast network (either acting as MLD
   proxy or multicast router).

1.1  Conventions and Terminology

   This document uses the terminology referring to PMIPv6 components as
   defined in [1]. 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.

   nMAG
      The new MAG or nMAG is the MAG where the MN is registered at the 
      end of the 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.

 

Contreras et al.          Expires May 3, 2012                   [Page 5]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

2  Overview

   The LMA is a key element within the PMIPv6 infrastructure. It traces
   the MN reachability along the PMIPv6 domain, therefore the LMA is the
   best element to store and forward the multicast subscription
   information to the rest of entities within the PMIPv6, that is, to
   the MAGs, as the MN moves.

   The LMA only requires to know the detailed subscription information
   (in terms of the IP addresses of both the multicast group subscribed,
   G, and the source delivering it, S) during the handover event. Apart
   from the handover event, it is not worthy to continuously inform the
   LMA about it. Such procedure would significantly increase the
   signaling load within the PMIPv6 domain without a clear benefit. The
   subscription information (S,G) is only critical during handover,
   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 do that, it will be necessary to extend the PMIPv6 protocol in
   several ways. First of all, a new mobility option is needed to pack
   the IP addresses of the current multicast subscription. Furthermore,
   additional messages are required to manage the interchange of the
   multicast information among PMIPv6 entities. Finally, some flags are
   defined to govern the process.

   Next sections provide the details.

 

Contreras et al.          Expires May 3, 2012                   [Page 6]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

3  PMIPv6 extensions

   This section outlines the extensions proposed to the PMIPv6 protocol
   specified in [1].

3.1  New "Active Multicast Subscription" mobility option

3.1.1  Option application rules

   A new TLV-encoded mobility option, "Active Multicast Subscription"
   option is defined for use with the PBU and PBA 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 by the MN, and the source delivering it as
   well. 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 taken place.

   This new option will be used, with the same aim, also by the new
   message Subscription Response described later in this document.

3.1.2  Option format

   The format of this new option is 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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |      Type     |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Multicast Source IP address                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Multicast Group IP address                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      To be defined

   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
 

Contreras et al.          Expires May 3, 2012                   [Page 7]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

      Unicast IP address of the node which injects the multicast content
      in the network.

   Multicast Group IP address
      Multicast IP address identifying the content which the MN
      subscribes to.

3.2  New "multicast Signaling" flag on PBU/PBA message headers

3.2.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 subject of the message.

   This flag will govern the multicast-related signaling between the LMA
   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.

3.2.1.1  Registration process

   These rules 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, without any further meaning.

      * If S=1 in the corresponding PBU message, two sub-cases can
      happen

         o S=1 in the PBA message if the multicast subscription
         information is provided in this message for the MN. When S=1,
         if the MN maintains an active multicast session, the PBA
 

Contreras et al.          Expires May 3, 2012                   [Page 8]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

         message will include the "Active Multicast Subscription"
         mobility option with the IP addresses of the subscribed group
         and the source providing it.

         o S=0 in the PBA message if the multicast subscription
         information is not provided in this message for the MN. 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 a MN being registered at nMAG. A way
         for obtaining later active multicast-subscription information
         is described later in this document.

3.2.1.2  De-registration process

   These rules apply for the Binding De-registration process

   o PBU message

      * S=0, it indicates that the MN has no active multicast session.

      * 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 a copy of the
   value received in the PBU message, without any further meaning.

3.2.2  New format of conventional PBU/PBA messages

3.2.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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

Contreras et al.          Expires May 3, 2012                   [Page 9]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

3.2.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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3  New "multicast Active" flag on LMA Binding Cache (and optionally on
   the MN's policy store)

3.3.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:

      - 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.

      - 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 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.

      - Flag S=1 & flag A=0: this situation represents the case where
      the nMAG supports multicast-related signaling for the MN being
 

Contreras et al.          Expires May 3, 2012                  [Page 10]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

      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.

      - 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.

3.4  New 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 [3].

3.4.1  Subscription Query message

3.4.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 of 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 0).

3.4.1.2  Message format

   The Subscription Query message has the following format.

 

Contreras et al.          Expires May 3, 2012                  [Page 11]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

3.4.2  Subscription Response message

3.4.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.

 

Contreras et al.          Expires May 3, 2012                  [Page 12]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

3.4.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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

      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)

 

Contreras et al.          Expires May 3, 2012                  [Page 13]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

      - 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.

3.5  New 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
      [3].

3.5.1  Multicast Activity Indication message

3.5.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 of
      the handover is of reactive type.

3.5.1.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 #   |A|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Contreras et al.          Expires May 3, 2012                  [Page 14]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

      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.

3.5.2  Multicast Activity Indication Acknowledge message

3.5.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.

3.5.2.2  Message format

   The Multicast Activity Indication message has the following format.
 

Contreras et al.          Expires May 3, 2012                  [Page 15]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

3.6  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 [3]
   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.

 

Contreras et al.          Expires May 3, 2012                  [Page 16]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

4  Signaling process description

   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.

4.1  Handover of proactive type

4.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.

   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 by
   the MN, and the source(s) delivering it(them), 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.

4.1.2  Message flow description

   The figure 1 summarizes this process.

 

Contreras et al.          Expires May 3, 2012                  [Page 17]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

       +-----+          +-----+          +-----+          +-----+
       | MN  |          |p-MAG|          | LMA |          |n-MAG|
       +-----+          +-----+          +-----+          +-----+
          |                |                |                |
          |                |==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 1. Proactive handover

   The sequence of messages is the following:

   1) A registered MN is receiving a multicast content which has been
   previously subscribed by sending an 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 May 3, 2012                  [Page 18]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   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 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 when the handover has been 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 [1].

   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 [1]. 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 present MN attached to it.
   From that instant, the multicast content is served to the MN.

4.2  Handover of reactive type

4.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.

   As the nMAG is not aware of any active multicast subscription of the
   MN, the nMAG will start a conventional registration process, by
 

Contreras et al.          Expires May 3, 2012                  [Page 19]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   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.

   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.

4.2.2  Message flow description

   The set of figures 2a to 2d summarize this process.

       +-----+ +-----+  +-----+          +-----+          +-----+
       | MN1 | | MN2 |  |p-MAG|          | LMA |          |n-MAG|
       +-----+ +-----+  +-----+          +-----+          +-----+
          |       |        |                |                |
   1)     |       |        |==Bi-Dir Tunnel=|                |
          |       |        |                |                |
          |  unicast data  |                |                |
          |<-v-v-v-v-v-v-v-|                |                |
          |       |        |                |                |
          |      unicast data               |                |
          |       |<-v-v-v-|                |                |
          |       |        |                |                |
          |  MLD Rep(S,G)  |                |                |
          |--------------->| Act Ind(start) |                |
   2)     |       |        |--------------->|                |
          |   (S,G) Data   |           (flag A = 1)          |
          |<---------------|   Act Ind Ack  |                |
          |       |        |<---------------|                |
          |       |        |                |                |
          ~       ~        ~                ~                ~
          ~       ~        ~                ~                ~

              Figure 2a. Reactive handover (steps 1 to 2)

   The sequence of messages is the following:

   1) A pair of MNs, named MN1 and MN2, are attached to the pMAG. Both
   MNs are multicast-enabled nodes, and both MNs are only receiving
   unicast traffic as usual in PMIPv6 domains, with no multicast
   subscription yet. At some point in time, the MN1 request to the pMAG
 

Contreras et al.          Expires May 3, 2012                  [Page 20]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   to be subscribed to the content identified by the IP addresses (S,G),
   by sending an standard MLD report from the MN to the pMAG. The pMAG
   will keep the multicast status state of the point-to-point link with
   the MN. The multicast flow (S,G) is then forwarded by the pMAG to the
   MN1.

   2) Due to this initial multicast subscription for the MN1, the pMAG
   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 pMAG to acknowledge the previous indication.

 

Contreras et al.          Expires May 3, 2012                  [Page 21]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

       +-----+ +-----+  +-----+          +-----+          +-----+
       | MN1 | | MN2 |  |p-MAG|          | LMA |          |n-MAG|
       +-----+ +-----+  +-----+          +-----+          +-----+
          |       |        |                |                |
          ~       ~        ~                ~                ~
          ~       ~        ~                ~                ~
          |       |        |                |                |
          |       |        |                |        MN1 Attached Event
          |       |        |                |                |
          |       |        |                |       PBU      |
   3)     |       |        |                |<---------------|
          |       |        |          LMA decision           |
          |       |        |                |                |
          |       |        |  Subscr Query  |                |
   4)     |       |        |<---------------|                |
          |       |        |                |                |
          |       |        |  Subscr Resp   |                |
   5)     |       |        |--------------->|                |
          |       |        |                |                |
          |       |        |    (Multicast Subscription      |
          |       |        |        info forwarding)         |
          |       |        |                |                |
          |       |        |                |   Ext'd PBA    |
   6)     |       |        |                |--------------->|
          |       |        |                |                |
   7)     |       |        |                |           Accept PBA,
          |       |        |                |      Multicast Group join
          |       |        |                |     and P-t-P status setup
          |       |        |                |                |
          |       |        |                |==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-|
          |       |        |                |                |
          |       |        |                |   (S,G) Data   |
          |<-------------------------------------------------|
          |       |        |                |                |
          ~       ~        ~                ~                ~
          ~       ~        ~                ~                ~

              Figure 2b. Reactive handover (steps 3 to 7)

   3) Some time later, 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.

 

Contreras et al.          Expires May 3, 2012                  [Page 22]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   4) 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.

   5) 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).

   6) After processing the pMAG answer, the LMA acknowledges 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.

   7) 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.

       +-----+ +-----+  +-----+          +-----+          +-----+
       | MN1 | | MN2 |  |p-MAG|          | LMA |          |n-MAG|
       +-----+ +-----+  +-----+          +-----+          +-----+
          |       |        |                |                |
          ~       ~        ~                ~                ~
          ~                ~                ~                ~
          |  MLD Done(S,G) |                |                | nMAG
   8)     |------------------------------------------------->X stops
          |       |        |                |  Act Ind(stop) | fwrding
   9)     |       |        |                |<---------------|
          |       |        |          (flag A = 0)           |
          |       |        |                |  Act Ind Ack   |
          |       |        |                |--------------->|
          |       |        |                |                |
          ~       ~        ~                ~                ~
          ~       ~        ~                ~                ~

              Figure 2c. Reactive handover (steps 8 to 9)

   8) 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 nMAG to request the cease of the multicast traffic
   delivery. As consequence, the nMAG will stop all the multicast
 

Contreras et al.          Expires May 3, 2012                  [Page 23]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   traffic forwarding to the MN1.

   9) After removing the active subscriptions for the MN1, the nMAG
   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 nMAG to acknowledge the previous
   indication.

       +-----+ +-----+  +-----+          +-----+          +-----+
       | MN1 | | MN2 |  |p-MAG|          | LMA |          |n-MAG|
       +-----+ +-----+  +-----+          +-----+          +-----+
          |       |        |                |                |
          ~       ~        ~                ~                ~
          ~       ~        ~                ~                ~
          |       |        |                |                |
          |       |        |                |        MN2 Attached Event
          |       |        |                |                |
          |       |        |                |       PBU      |
   10)    |       |        |                |<---------------|
          |       |        |          LMA decision           |
          |       |        |                |      PBA       |
   11)    |       |        |                |--------------->|
          |       |        |                |                |
   12)    |       |        |                |           Accept PBA
          |       |        |                |                |
          |       |        |                |  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-|
          |       |        |                |                |

              Figure 2d. Reactive handover(steps 10 to 12)

   10) 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 neither 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.

   11) 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. The nMAG
   then process the extended PBA message.

   12) The nMAG is now ready to forward the unicast traffic to the MN2.

 

Contreras et al.          Expires May 3, 2012                  [Page 24]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

4.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 loosing 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.

4.2.4  Prevention of large delays of the binding acknowledgement for
   unicast traffic

   Attending to the message sequences detailed above for reactive
   handovers, in case the LMA has to request the multicast subscription
   information to 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 to the LMA towards the MN, a mechanism
   should be implemented to decouple multicast from unicast traffic
   reception by the MN.

   The figures 3a and 3b show this mechanism:

 

Contreras et al.          Expires May 3, 2012                  [Page 25]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

       +-----+          +-----+          +-----+          +-----+
       | MN  |          |p-MAG|          | LMA |          |n-MAG|
       +-----+          +-----+          +-----+          +-----+
          |                |                |                |
   1)     |                |==Bi-Dir Tunnel=|                |
          |                |                |                |
          |  unicast data  |                |                |
          |<-v-v-v-v-v-v-v-|                |                |
          |                |                |                |
          | Multicast Data |                |                |
          |<---------------|                |                |
          |                |                |                |
          ~                ~                ~                ~
          ~                ~                ~                ~
   Figure 3a. Decoupling of unicast and multicast signaling (step 1)

   The sequence of messages is the following:

   1) An MN, named MN1, is attached to the pMAG. The MN is a multicast-
   enabled node, and it is receiving both unicast and multicast traffic
   simultaneously.

 

Contreras et al.          Expires May 3, 2012                  [Page 26]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

       +-----+          +-----+          +-----+          +-----+
       | MN  |          |p-MAG|          | LMA |          |n-MAG|
       +-----+          +-----+          +-----+          +-----+
          |                |                |                |
          ~                ~                ~                ~
          ~                ~                ~                ~
          |                |                |                |
          |                |                |        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 3b. Decoupling of unicast and multicast signaling (steps 2 to 8)

 

Contreras et al.          Expires May 3, 2012                  [Page 27]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

   2) Some time later, the MN1 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 MN1, 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 duration 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=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 by another MN connection).

   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 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 also be served
   to the MN.

 

Contreras et al.          Expires May 3, 2012                  [Page 28]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

5  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 [4].
   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
   [6].

   The Multicast Tree Mobility Anchor (MTMA) solution in [6] 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.

   In case of 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 memo.

6  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 [7], 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 [7] avoids packet loss during the handover. Even so,
   the proposal in this memo is still useful, because reducing the time
   required to set up multicast traffic delivery in the nMAG minimizes
   the buffering needed at the pMAG.

   In any case, because the feature in [7] is dependent on the
   capabilities of the underlying radio technology, and that not all the
   multicast applications could take benefit of it, that functionality
   can be seen as optional for multicast handover optimization.
 

Contreras et al.          Expires May 3, 2012                  [Page 29]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

7  Security Considerations

   TBD.

8  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.

9  References

9.1  Normative References

   [1]   S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B.
         Patil, "Proxy Mobile IPv6", RFC 5213, Augurst 2008.

   [2]   S. Deering, W. Fenner, B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [3]   D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

9.2  Informative References

   [4]   T.C. Schmidt, M. Waehlisch, and S. Krishnan, "A Minimal
         Deployment Option for Multicast Listeners in PMIPv6 Domains",
         RFC6224, April 2011.

   [5]   D. von Hugo, H. Asaeda, B. Sarikaya, 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.

   [6]   J.C. Zuniga, L.M. Contreras, C.J. Bernardos, S. Jeon, and Y.
         Kim, "Mobile Multicast Routing Optimizations", draft-zuniga-
 

Contreras et al.          Expires May 3, 2012                  [Page 30]
INTERNET DRAFT     Rapid acquisition of subscription    October 31, 2011

         multimob-pmipv6-ropt-01, (work in progress), October 2011.

   [7]   H. Yokota, Chowdhury, K., Koodli, R., Patil, B., and F. Xia,
         "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September
         2010

10  Acknowledgments

   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
   and Innovation (MICINN) of Spain under the QUARTET project (TIN2009-
   13992-C02-01). 

   The research of Ignacio Soto also has received funding from the
   Spanish MICINN through the I-MOVING project (TEC2010-18907).

Author's Addresses

   Luis M. Contreras
   Telefonica I+D
   Email: lmcm@tid.es

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Email: cjbc@it.uc3m.es

   Ignacio Soto
   Universidad Politecnica de Madrid
   Email: isoto@dit.upm.es

Contreras et al.          Expires May 3, 2012                  [Page 31]