[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                       T C. Schmidt
Internet-Draft                                               HAW Hamburg
Intended status: Standards Track                            M. Waehlisch
Expires: September 7, 2010                          link-lab & FU Berlin
                                                               R. Koodli
                                                           Cisco Systems
                                                            G. Fairhurst
                                                  University of Aberdeen
                                                          March 06, 2010


   Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers
           draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01

Abstract

   Fast handover protocols for MIPv6 and PMIPv6 define mobility
   management procedures that support unicast communication at reduced
   handover latencies.  Fast handover base operations do not affect
   multicast communication, and hence do not accelerate handover
   management for native multicast listeners.  Many multicast
   applications like IPTV or conferencing, though, are comprised of
   delay-sensitive real-time traffic and could strongly benefit from
   fast handover execution.  This document specifies extension of the
   Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy
   Mobile IPv6 (PFMIPv6) protocols to include multicast traffic
   management in fast handover operations.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

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

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



Schmidt, et al.         Expires September 7, 2010               [Page 1]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   This Internet-Draft will expire on September 7, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Schmidt, et al.         Expires September 7, 2010               [Page 2]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Multicast Context Transfer between Access Routers  . . . .  5
     3.2.  Protocol Operations Specific to FMIPv6 . . . . . . . . . .  7
     3.3.  Protocol Operations Specific to PFMIPv6  . . . . . . . . .  9
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Common Protocol Operations . . . . . . . . . . . . . . . . 12
     4.2.  Protocol Operations Specific to FMIPv6 . . . . . . . . . . 12
     4.3.  Protocol Operations Specific to PFMIPv6  . . . . . . . . . 12
       4.3.1.  IPv4 Support Considerations  . . . . . . . . . . . . . 12
   5.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Multicast Indicator for Proxy Router Advertisement
           (PrRtAdv)  . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Extensions to Existing Mobility Header Messages  . . . . . 12
     5.3.  New Multicast Mobility Option  . . . . . . . . . . . . . . 13
     5.4.  New Multicast Acknowledgement Option . . . . . . . . . . . 14
     5.5.  Length Considerations: Number of Records and Addresses . . 16
     5.6.  MLD (IGMP) Compatibility Aspects . . . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19






















Schmidt, et al.         Expires September 7, 2010               [Page 3]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


1.  Introduction

   Mobile IPv6 [RFC3775] defines a network layer mobility protocol
   involving mobile nodes participation, while Proxy Mobile IPv6
   [RFC5213] provides a mechanism without requiring mobility protocol
   operations at a Mobile Node (MN).  Both protocols introduce traffic
   disruptions on handovers that may be intolerable in many application
   scenarios.  Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568], and Fast
   Handovers for Proxy Mobile IPv6 (PFMIPv6) [I-D.ietf-mipshop-pfmipv6]
   improve these handover delays for unicast communication to the order
   of the maximum delay needed for link switching and signaling between
   Access Routers (ARs) or Mobile Access Gateways (MAGs)
   [FMIPv6-Analysis].

   No dedicated treatment of seamless multicast data reception has been
   proposed by any of the above protocols.  MIPv6 only roughly defines
   multicast for Mobile Nodes using a remote subscription approach or a
   home subscription through bi-directional tunneling via the Home Agent
   (HA).  Multicast forwarding services have not been specified at all
   in [RFC5213], but are subject to current specification
   [I-D.ietf-multimob-pmipv6-base-solution].  It is assumed throughout
   this document that mechanisms and protocol operations are in place to
   transport multicast traffic to ARs.  Symbolically, these operations
   are referred to as 'JOIN/LEAVE' of an AR, while the explicit
   techniques to manage multicast transmission are beyond the scope of
   this document.

   Mobile multicast protocols need to serve applications like IPTV with
   voluminous content streams to be distributed to potentially large
   numbers of receivers, and therefore should preserve the multicast
   nature of packet distribution and approximate optimal routing
   [RFC5757].  It is undesirable to rely on home tunneling for
   optimizing multicast.  Unencapsulated, native multicast forwarding
   requires forwarding states, which will not be transferred between
   access routers by the unicast fast handover protocols.  Thus
   multicast traffic will not experience expedited handover performance,
   but an MN - or its corresponding MAG in PMIPv6 - can continuously
   perform remote subscriptions in the visited networks.

   This document specifies extension of FMIPv6 and PFMIPv6 for including
   multicast traffic management in fast handover operations.  The
   solution common to both underlying protocols defines the per group
   transfer of multicast contexts between ARs or MAGs.  The protocol
   defines corresponding message extensions necessary for carrying group
   context information independent of the particular handover protocol
   in use.  ARs or MAGs are then enabled to treat multicast traffic in
   correspondence to fast unicast handovers and with analogous
   performance.  No protocol changes are introduced that prevent a



Schmidt, et al.         Expires September 7, 2010               [Page 4]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   multicast unaware node from performing fast handovers with multicast
   aware ARs or MAGs.

   This specification is applicable when a mobile node has joined and
   maintains one or several multicast group subscriptions prior to
   undergoing a fast handover.  It does not pose any requirements on
   multicast routing protocols in use, nor are the ARs or MAGs assumed
   to be multicast routers.  It assumes network conditions, though, that
   allow native multicast reception in both, the previous and new access
   network.  Methods to bridge regions without native multicast
   connectivity are beyond the scope of this document.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   The use of the term, "silently ignore" is not defined in RFC 2119.
   However, the term is used in this document and can be similarly
   construed.

   This document uses the terminology of [RFC5568],
   [I-D.ietf-mipshop-pfmipv6], [RFC3775], and [RFC5213].  In addition,
   the following terms are introduced:


3.  Protocol Overview

   The reference scenario for multicast fast handover is illustrated in
   Figure 1.




















Schmidt, et al.         Expires September 7, 2010               [Page 5]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


                             ***  ***  ***  ***
                            *   **   **   **   *
                           *                    *
                            *  Multicast Cloud *
                           *                    *
                            *   **   **   **   *
                             ***  ***  ***  ***
                                  /      \
                                 /        \
                                /          \
                    +........../..+      +..\..........+
                    . +-------+-+ .______. +-+-------+ .
                    . |   PAR   |()_______)|   NAR   | .
                    . |  (PMAG) | .      . |  (NMAG) | .
                    . +----+----+ .      . +----+----+ .
                    .      |      .      .      |      .
                    .   ___|___   .      .   ___|___   .
                    .  /       \  .      .  /       \  .
                    . (  P-AN   ) .      . (  N-AN   ) .
                    .  \_______/  .      .  \_______/  .
                    .      |      .      .      |      .
                    .   +----+    .      .   +----+    .
                    .   | MN |  ---------->  | MN |    .
                    .   +----+    .      .   +----+    .
                    +.............+      +.............+

               Figure 1: Reference Network for Fast Handover

3.1.  Multicast Context Transfer between Access Routers

   In a fast handover scenario (cf. Figure 1), ARs/MAGs establish a
   mutual binding and provide the capability to exchange context
   information concerning the MN.  This context transfer will be
   triggered by detecting MN's forthcoming move to a new AR and assist
   the MN to immediately resume communication on the new subnet link
   using its previous IP address.  In contrast to unicast, multicast
   stream reception does not primarily depend on address and binding
   cache management, but requires distribution trees to adapt such that
   traffic follows the MN.  This process may be significantly slower
   than fast handover management [RFC5757].  Multicast listeners at
   handover may take twofold advantage of including the multicast groups
   under subscription in context transfer.  First, the NAR can
   proactively join the desired groups as soon as it gains knowledge
   thereof.  Second, multicast streams may be included in traffic
   forwarding via the tunnel established from PAR to NAR.

   There are two modes of operation in FMIPv6 and in PFMIPv6.  The
   predictive mode allows for AR-binding and context transfer prior to



Schmidt, et al.         Expires September 7, 2010               [Page 6]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   MN's handover, while in the reactive mode, these steps are executed
   after the MN's re-attachment to NAR has been detected.  Details of
   the signaling schemes differ between FMIPv6 and PFMIPv6 and are
   outlined in Section 3.2 and Section 3.3.

   In a predictive fast handover, the access router (e.g., PAR in
   Figure 1) learns about the impending movement of the MN and
   simultaneously about the multicast group context as specified in
   Section 3.2 and Section 3.3.  Thereafter, PAR will initiate an AR-
   binding and context transfer by transmitting a HI message to NAR.  HI
   is extended by multicast group states carried in mobility header
   options as defined in Section 5.3.  On reception of the HI message,
   NAR returns a multicast acknowledgement in its HACK answer that per
   group indicates its ability to support the requested group, as well
   as its willingness to receive multicast traffic forwarded from PAR
   (see Section 5.4).  There are several reasons to waive forwarding,
   e.g., the group may already be under native subscription or capacity
   constraints may hinder decapsulation of additional streams at the
   NAR.  For the groups requested, PAR will add the tunnel interface to
   its multicast forwarding database, so that multicast streams are
   forwarded in parallel to unicast traffic.  NAR, taking the role of an
   MLD proxy [RFC4605] with the upstream tunnel interface to PAR, will
   submit an MLD report to request for the desired groups, but will
   terminate multicast forwarding [RFC3810] from PAR, as soon as group
   traffic natively arrives.  In addition, NAR immediately joins all
   groups that are not already under subscription using its loopback
   interface, and starts multicast forwarding after the MN has arrived.

   In a reactive fast handover, PAR will learn about the movement of the
   MN, after the latter has re-associated with the new access network.
   Also from the new link, it will be informed about the multicast
   context of the MN.  As group membership information are present at
   the new access network prior to context transfer, MLD join signaling
   can proceed in parallel to HI/HACK exchange.  Depending on the
   specific network topology, multicast traffic for some groups may
   natively arrive before it is forwarded from PAR.  However, PAR-NAR
   forwarding SHOULD be procured for groups in far reach.

   In both modes of operation, it is the responsibility of the PAR
   (PMAG) to properly consider the departure of the MN for the local
   group management.  Depending on the multicast state management, link
   type and MLD parameters deployed (cf., [RFC5757]), it SHOULD take
   appropriate actions to adjust multicast service to requirements of
   the remaining nodes.

   In this way, the MN will be able to participate in multicast group
   communication with handover experiences comparable to unicast
   performance, while network resources are preserved whenever possible.



Schmidt, et al.         Expires September 7, 2010               [Page 7]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


3.2.  Protocol Operations Specific to FMIPv6

   ARs that provide multicast support in FMIPv6 will advertise this
   general service by setting an indicator bit (M-bit) in its PrRtAdv
   message as defined in Section 5.1.  Additional details about the
   multicast service support, e.g., flavors and groups, will be
   exchanged within HI/HACK dialogs later at handovers.

   An MN operating FMIPv6 will actively initiate the handover management
   by submitting a fast binding update (FBU).  The MN, which is aware of
   the multicast groups it wishes to maintain, will attach mobility
   options containing its group states (see Section 5.3) to the FBU, and
   thereby inform ARs about its multicast context.  ARs will use these
   multicast context options for inter-AR context transfer.

   In predictive mode, FBU is issued on the previous link and received
   by PAR as displayed in Figure 2.  PAR will extract the multicast
   context options and append them to its HI message.  From the HACK
   message, PAR will redistribute the multicast acknowledgement by
   adding the corresponding mobility options to its FBACK message.  From
   receiving FBACK, the MN will learn about a per group multicast
   support in the new access network.  If some groups or a multicast
   flavour are not supported, it may decide on taking actions to
   compensate the missing service.  Note that the proactive multicast
   context transfer may proceed successfully, even if the MN misses the
   FBACK message on the previous link.

























Schmidt, et al.         Expires September 7, 2010               [Page 8]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


                  MN                    PAR                    NAR
                   |                     |                      |
                   |------RtSolPr------->|                      |
                   |<-----PrRtAdv--------|                      |
                   |                     |                      |
                   |                     |                      |
                   |---------FBU-------->|----------HI--------->|
                   | (Multicast MobOpt)  | (Multicast MobOpt)   |
                   |                     |                      |
                   |                     |<--------HAck---------|
                   |                     | (Multicast AckOpt)   |
                   |                     |                   Join to
                   |                     |                  Multicast
                   |                     |                   Groups
                   |                     |                      |
                   |       <-----FBack---|--FBack------>        |
                   |  (Multicast AckOpt) | (Multicast AckOpt)   |
                   |                     |                      |
                disconnect             forward                  |
                   |                   packets  ===============>|
                   |                     |                      |
                   |                     |                      |
                connect                  |                      |
                   |                     |                      |
                   |------------UNA --------------------------->|
                   |<=================================== deliver packets
                   |                                            |

            Figure 2: Predictive Multicast Handover for FMIPv6

   The call flow for reactive mode is visualized in Figure 3.  After
   attaching to the new access link and performing an unsolicited
   neighbor advertisement (UNA), the MN issues an FBU which NAR forwards
   to PAR without processing.  At this time, MN is able to re-join all
   desired multicast groups without relying on AR assistance.
   Nevertheless, multicast context options are exchanged in the HI/HACK
   dialog to facilitate intermediate forwarding of requested streams.
   Note that group traffic may already arrive from MN's subscription at
   the time NAR receives the HI message.  Such streams may be
   transparently excluded from forwarding by setting an appropriate
   multicast acknowledge option.  In any case, NAR MUST ensure that not
   more than one stream of the same group is forwarded to the MN.









Schmidt, et al.         Expires September 7, 2010               [Page 9]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


                  MN                    PAR                    NAR
                   |                     |                      |
                   |------RtSolPr------->|                      |
                   |<-----PrRtAdv--------|                      |
                   |                     |                      |
                disconnect               |                      |
                   |                     |                      |
                   |                     |                      |
                connect                  |                      |
                   |-------UNA-----------|--------------------->|
                   |-------FBU-----------|---------------------)|
                   | (Multicast MobOpt)  |<-------FBU----------)|
                   |                     |                      |
                Join to                  |                      |
               Multicast                 |                      |
                Groups                   |                      |
                   |                     |----------HI--------->|
                   |                     |  (Multicast MobOpt)  |
                   |                     |<-------HAck----------|
                   |                     |  (Multicast AckOpt)  |
                   |                     |                      |
                   |                     |(HI/HAck if necessary)|
                   |                     |                      |
                   |                   forward                  |
                   |              packets(including FBack)=====>|
                   |                     |                      |
                   |<=================================== deliver packets
                   |                                            |

             Figure 3: Reactive Multicast Handover for FMIPv6

3.3.  Protocol Operations Specific to PFMIPv6

   In a proxy mobile IPv6 environment, the MN remains agnostic of
   network layer changes, and fast handover operations are pursued by
   the access routers or MAGs.  The handover initiation, or the re-
   association respectively are managed by the access networks.
   Consequently, access routers need to be aware of multicast membership
   states at the mobile node.  There are two ways to obtain record of
   MN's multicast membership.  First, MAGs may perform an explicit
   tracking (cf., [RFC4605], [I-D.ietf-multimob-pmipv6-base-solution])
   or extract membership status from forwarding states at node-specific
   point-to-point links.  Second, routers may perform general queries at
   handovers.  Both methods are equally applicable, which leaves a final
   choice to the implementation.  In either case, the PAR will become
   knowledgeable about multicast group subscriptions of the MN.

   In predictive mode, the PMAG (PAR) will learn about the upcoming



Schmidt, et al.         Expires September 7, 2010              [Page 10]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   movement of the mobile node.  Without explicit tracking, it will
   immediately submit a general MLD query and learn about the multicast
   groups under subscription.  As displayed in Figure 4, it will
   initiate binding and context transfer with the NMAG (NAR) by issuing
   a HI message that is augmented by multicast contexts in the mobility
   options defined in Section 5.3).  NAR will extract multicast context
   information and act as described in Section 3.1.


                                             PMAG          NMAG
           MN           P-AN       N-AN        (PAR)         (NAR)
           |             |          |            |             |
           |    Report   |          |            |             |
           |---(MN ID,-->|          |            |             |
           |  New AP ID) |          |            |             |
           |             |    HO Indication      |             |
           |             |--(MN ID, New AP ID)-->|             |
           |             |          |            |             |
           |             |          |         Optional:        |
           |             |          |         MLD Query        |
           |             |          |            |             |
           |             |          |            |------HI---->|
           |             |          |            |(Multicast MobOpt)
           |             |          |            |             |
           |             |          |            |<---HAck-----|
           |             |          |            |(Multicast AckOpt)
           |             |          |            |             |
           |             |          |            |          Join to
           |             |          |            |         Multicast
           |             |          |            |          Groups
           |             |          |            |             |
           |             |          |            |HI/HAck(optional)
           |             |          |            |<- - - - - ->|
           |             |          |            |             |
           |             |          |          forward         |
           |             |          |          packets =======>|
       disconnect        |          |            |             |
           |             |          |            |             |
        connect          |          |            |             |
           |    MN-AN connection    |    AN-MAG connection     |
           |<----establishment----->|<----establishment------->|
           |             |          |  (substitute for UNA)    |
           |             |          |            |             |
           |<========================================== deliver packets
           |             |          |            |             |


            Figure 4: Predictive Multicast Handover for PFMIPv6



Schmidt, et al.         Expires September 7, 2010              [Page 11]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   In reactive mode, the NMAG (NAR) will learn about MN's attachment to
   the N-AN and establish connectivity by means of PMIPv6 protocol
   operations.  However, it will have no knowledge about multicast
   states at the MN.  Triggered by MN's attachment, the NMAG will
   inquire on group memberships by submitting a general MLD query and
   thereafter join the requested groups.  In the case of a reactive
   handover, the binding is initiated by NMAG, and the HI/HACK message
   semantic is inverted (see [I-D.ietf-mipshop-pfmipv6]).  For multicast
   context transfer, the NMAG attaches those group identifiers in
   multicast mobility options which it requests for forwarding.  Using
   the identical syntax in its option headers as defined in Section 5.4,
   PMAG acknowledges the group forwarding request in its HACK answer.
   The corresponding call flow is displayed in Figure 5.


                                             PMAG          NMAG
           MN         P-AN       N-AN        (PAR)         (NAR)
           |           |          |            |             |
       disconnect      |          |            |             |
           |           |          |            |             |
        connect        |          |            |             |
           |           |          |            |             |
           |   MN-AN connection   |    AN-MAG connection     |
           |<---establishment---->|<----establishment------->|
           |           |          |(substitute for UNA & FBU)|
           |           |          |            |             |
           |           |          |            |         MLD Query
           |           |          |            |             |
           |           |          |            |          Join to
           |           |          |            |         Multicast
           |           |          |            |          Groups
           |           |          |                          |
           |           |          |            |<------HI----|
           |           |          |            |(Multicast MobOpt)
           |           |          |            |             |
           |           |          |            |---HAck----->|
           |           |          |            |(Multicast AckOpt)
           |           |          |            |             |
           |           |          |            |             |
           |           |          |            |HI/HAck(optional)
           |           |          |            |<- - - - - ->|
           |           |          |            |             |
           |           |          |          forward         |
           |           |          |          packets =======>|
           |           |          |            |             |
           |<======================================== deliver packets
           |           |          |            |             |




Schmidt, et al.         Expires September 7, 2010              [Page 12]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


             Figure 5: Reactive Multicast Handover for PFMIPv6


4.  Protocol Details

4.1.  Common Protocol Operations

   :::TODO:

4.2.  Protocol Operations Specific to FMIPv6

   :::TODO:

4.3.  Protocol Operations Specific to PFMIPv6

   :::TODO:

4.3.1.  IPv4 Support Considerations

   :::TODO:


5.  Message Formats

5.1.  Multicast Indicator for Proxy Router Advertisement (PrRtAdv)

   An FMIPv6 AR will indicate its multicast support by activating an
   M-bit in its Proxy Router Advertisements (PrRtAdv).  The message
   extension is of the following form.
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |      Code     |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Subtype    |M|  Reserved   |           Identifier          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Options ...
       +-+-+-+-+-+-+-+-+-+-+-+-

     Figure 6: Multicast Indicator Bit for Proxy Router Advertisement
                             (PrRtAdv) Message

5.2.  Extensions to Existing Mobility Header Messages

   Multicast listener context of an MN is transferred in fast handover
   operations from PAR/PMAG to NAR/NMAG within a new Multicast Mobility
   Option, and acknowledged by a corresponding Acknowledgement Option.
   Depending on the specific handover scenario and protocol in use, the



Schmidt, et al.         Expires September 7, 2010              [Page 13]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   corresponding option is included within the mobility option list of
   HI/HAck only (PFMIPv6), or of FBU/FBAck/HI/HAck (FMIPv6).

5.3.  New Multicast Mobility Option

   The Multicast Mobility Option contains the current listener state
   record of the MN as obtained from the MLD Report message, and has the
   format displayed in Figure 7.
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |   Length      | Option-Code   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                    MLD (IGMP) Report Payload                  +
       ~                                                               ~
       ~                                                               ~
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: Mobility Header Multicast Option

   Type: TBD

   Length: 8-bit unsigned integer.  The size of this option in 8 octets
   including the Type, Option-Code, and Length fields.

   Option-Code:

      1: IGMPv3 Payload Type

      2: MLDv2 Payload Type

      3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode

      4: MLDv2 Payload Type from MLDv1 Compatibility Mode

   Reserved: MUST be set to zero by the sender and MUST be ignored by
   the receiver.

   MLD (IGMP) Report Payload: this field is composed of the MLD (IGMP)
   Report message after stripping its ICMP header line.  Corresponding
   message formats are defined for MLDv2 in [RFC3810], and for IGMPv3 in
   [RFC3376].



Schmidt, et al.         Expires September 7, 2010              [Page 14]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   Figure 8 shows the Report Payload for MLDv2, while the payload format
   for IGMPv3 is defined correspondingly (see Section 5.2. of [RFC3810],
   or Section 4.2 of [RFC3376]) for the definition of Multicast Address
   Records).
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved            |No of Mcast Address Records (M)|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |     .                                                               .
    .                  Multicast Address Record [1]                 .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                  Multicast Address Record [2]                 .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    .                               .                               .
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                  Multicast Address Record [M]                 .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 8: MLDv2 Report Payload

5.4.  New Multicast Acknowledgement Option

   The Multicast Acknowledgement Option reports on the status of context
   transfer and contains the list of state records that could not
   successfully be transferred to the next access network.  It has the
   format displayed in Figure 9.












Schmidt, et al.         Expires September 7, 2010              [Page 15]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |   Length      | Option-Code   |    Status     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +           MLD (IGMP) Unsupported Report Payload               +
       ~                                                               ~
       ~                                                               ~
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 9: Mobility Header Multicast Acknowledgement Option

   Type: TBD

   Length: 8-bit unsigned integer.  The size of this option in 8 octets.
   The length is 1 when MLD (IGMP) Unsupported Report Payload field
   contains no Mcast Address Record.

   Option-Code: 0

   Status:

      1: Report Payload type unsupported

      2: Requested group service unsupported

      3: Requested group service administratively prohibited

   Reserved: MUST be set to zero by the sender and MUST be ignored by
   the receiver.

   MLD (IGMP) Unsupported Report Payload: this field is syntactically
   identical to the MLD (IGMP) Report Payload field described in
   Section 5.3, but is only composed of those multicast address records
   that are not supported or prohibited in the new access network.  This
   field MUST always contain the first header line (reserved field and
   No of Mcast Address Records), but MUST not contain any Mcast Address
   Record, if status code equals 1.

   Note that group subscriptions to specific sources may be rejected at
   the destination network, and thus the composition of multicast
   address records may differ from initial requests within an MLD (IGMP)



Schmidt, et al.         Expires September 7, 2010              [Page 16]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   Report Payload option.

5.5.  Length Considerations: Number of Records and Addresses

   Mobility Header Messages exchanged in HI/HACK and FBU/FBACK dialogs
   impose length restrictions on multicast context records.  The maximal
   payload length available in FBU/FBACK messages is MTU - 40 octets
   (IPv6 Header) - 6 octets (Mobility Header) - 6 octets (FBU/FBACK
   Header).  For example, on an Ethernet link with an MTU of 1500
   octets, not more than 72 Multicast Address Records of minimal length
   (without source states) may be exchanged.  In typical handover
   scenarios, this number reduces further according to unicast context
   and Binding Authorization data.  Context information may be
   fragmented in PFMIPv6 over several HI/HACK messages.  However, a
   single MLDv2 Report Payload MUST not be fragmented.  Hence, for a
   single Multicast Address Record on an Ethernet link, the number of
   source addresses is limited to 89.

5.6.  MLD (IGMP) Compatibility Aspects

   Access routers (MAGs) MUST support MLDv2 (IGMPv3).  To enable
   multicast service for MLDv1 (IGMPv2) listeners, the routers MUST
   follow the interoperability rules defined in [RFC3810] ([RFC3376])
   and set the Multicast Address Compatibility Mode appropriately.  When
   Multicast Address Compatibility Mode is MLDv1 (IGMPv2), a router
   internally translates the following MLDv1 (IGMPv2) messages for that
   multicast address to their MLDv2 (IGMPv2) equivalents and uses these
   messages in the context transfer.  The current state of Compatibility
   Mode is translated into the code of the Multicast Mobility Option as
   defined in Section 5.3.  A NAR (nMAG) receiving a Multicast Mobility
   Option during handover will switch to the minimum obtained of its
   previous and newly learned value of MLD (IGMP) Compatibility Mode for
   continued operation.


6.  Security Considerations

   Security vulnerabilities that exceed issues discussed in the base
   protocols of this document ([RFC5568], [I-D.ietf-mipshop-pfmipv6],
   [RFC3810], [RFC3376]) are identified as follows.

   Multicast context transfer at predictive handovers implements group
   states at remote access routers and may lead to group subscriptions
   without further validation of the multicast service requests.
   Thereby a NAR (nMAG) is requested to cooperate in potentially complex
   multicast re-routing and may receive large volumes of traffic.
   Malicious or inadvertent multicast context transfers may place
   significant burdens of route establishment and traffic management



Schmidt, et al.         Expires September 7, 2010              [Page 17]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   onto the backbone infrastructure and the access router itself.  Rapid
   re-routing or traffic overloads can be mitigated by a rate control at
   the AR that applies to the frequency of traffic redirects and to the
   total number of subscriptions.  In addition, the wireless access
   network remains protected from multicast data injection until the
   requesting MN attaches to the new location.


7.  IANA Considerations

   This document defines new Mobility Options that need Type assignment
   from the Mobility Options Type registry at
   http://www.iana.org/assignments/mobility-parameters ....


8.  Acknowledgments

   Protocol extensions to support multicast in Fast Mobile IPv6 have
   been loosely discussed since several years.  Repeated attempts have
   been taken to define corresponding protocol extensions.  The first
   draft [fmcast-mip6] was presented by Suh, Kwon, Suh, and Park already
   in 2004.

   This work was stimulated by many fruitful discussions in the MobOpts
   research group.  We would like to thank all active members for
   constructive thoughts and contributions on the subject of multicast
   mobility.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

   [I-D.ietf-mipshop-pfmipv6]
              Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6",



Schmidt, et al.         Expires September 7, 2010              [Page 18]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


              draft-ietf-mipshop-pfmipv6-12 (work in progress),
              December 2009.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

9.2.  Informative References

   [RFC5757]  Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
              Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
              and Brief Survey", RFC 5757, February 2010.

   [fmcast-mip6]
              Suh, K., Kwon, D., Suh, Y., and Y. Park, "Fast Multicast
              Protocol for Mobile IPv6 in the fast handovers
              environments", draft-suh-mipshop-fmcast-mip6-00 (work in
              progress), July 2004.

   [FMIPv6-Analysis]
              Schmidt, TC. and M. Waehlisch, "Predictive versus Reactive
              - Analysis of Handover Performance and Its Implications on
              IPv6 and Multicast Mobility", Telecommunication
              Systems Vol 33, No. 1-3, pp. 131-154, November 2005.

   [I-D.ietf-multimob-pmipv6-base-solution]
              Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in PMIPv6
              Domains", draft-ietf-multimob-pmipv6-base-solution-00
              (work in progress), February 2010.

   [PMIPv6v4]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-04
              (work in progress), July 2008.





Schmidt, et al.         Expires September 7, 2010              [Page 19]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


Appendix A.  Change Log

   The following changes have been made from
   draft-schmidt-multimob-fmipv6-pfmipv6-multicast-00.

   1.  Editorial improvements & clarifications.

   2.  Section on length considerations for multicast context records
       added.

   3.  Section on MLD/IGMP compatibility aspects added.

   4.  Security section added.


Authors' Addresses

   Thomas C. Schmidt
   HAW Hamburg
   Dept. Informatik
   Berliner Tor 7
   Hamburg,   D-20099
   Germany

   Email: Schmidt@informatik.haw-hamburg.de


   Matthias Waehlisch
   link-lab & FU Berlin
   Hoenower Str. 35
   Berlin  D-10318
   Germany

   Email: mw@link-lab.net


   Rajeev Koodli
   Cisco Systems
   30 International Place
   Xuanwu District,
   Tewksbury  MA 01876
   USA

   Email: rkoodli@cisco.com







Schmidt, et al.         Expires September 7, 2010              [Page 20]


Internet-Draft        Multicast for FMIPv6/PFMIPv6            March 2010


   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Aberdeen  AB24 3UE
   UK

   Email: gorry@erg.abdn.ac.uk












































Schmidt, et al.         Expires September 7, 2010              [Page 21]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/