MULTIMOB Group                                                 H. Asaeda
Internet-Draft                                           Keio University
Intended status: Standards Track                                P. Seite
Expires: April 30, 2009                                   France Telecom
                                                                  J. Xia
                                           Huawei Technologies Co., Ltd.
                                                        October 27, 2008


                    PMIPv6 Extensions for Multicast
                draft-asaeda-multimob-pmip6-extension-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on April 30, 2009.















Asaeda, et al.           Expires April 30, 2009                 [Page 1]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


Abstract

   This document describes Proxy Mobile IPv6 (PMIPv6) extensions and
   solutions to support IP multicast.  The Mobile Access Gateway (MAG)
   and the Local Mobility Anchor (LMA) are the mobility entities defined
   in the PMIPv6 protocol and establish a bi-directional tunnel to
   manage mobility for mobile nodes within the Proxy Mobile IPv6 domain.
   This document defines the roles of LMA and MAG to support IP
   multicast for the mobile nodes.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  5
     2.1.  Conventions Used in This Document  . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Multicast Communication in PMIPv6  . . . . . . . . . . . .  6
     3.2.  Protocol Sequence for Joining and Leaving Multicast
           Channels . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . .  9
     4.1.  LMA Operating As PIM-SM Router . . . . . . . . . . . . . .  9
     4.2.  LMA Operating As MLD Proxy . . . . . . . . . . . . . . . .  9
     4.3.  LMA Operating As AMT Relay . . . . . . . . . . . . . . . .  9
   5.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . . 10
     5.1.  MAG Operating As MLD Proxy . . . . . . . . . . . . . . . . 10
     5.2.  MAG Operating As AMT Gateway . . . . . . . . . . . . . . . 10
     5.3.  MAG Operating As Multicast Router  . . . . . . . . . . . . 10
   6.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 12
   7.  Dual-Mode Implementation . . . . . . . . . . . . . . . . . . . 13
   8.  Handover Process . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  MAG Operating As MLD Proxy . . . . . . . . . . . . . . . . 14
     8.2.  MAG Operating As Multicast Router  . . . . . . . . . . . . 17
     8.3.  Multicast Context Transfer Data Format . . . . . . . . . . 20
     8.4.  Proxy Binding Update with Multicast Extension  . . . . . . 21
   9.  IPv4-Only and Dual-Stack Node Support  . . . . . . . . . . . . 25
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     13.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32






Asaeda, et al.           Expires April 30, 2009                 [Page 2]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [2] enables network-based mobility for
   IPv6 mobile nodes (MNs) that do not implement any mobility protocols.
   The Local Mobility Anchor (LMA) is the topological anchor point to
   manages the mobile node's binding state.  The Mobile Access Gateway
   (MAG) is an access router or gateway that manages the mobility-
   related signaling for a mobile node.  MN is attached to the Proxy
   Mobile IPv6 Domain (PMIPv6-Domain) that includes LMA and MAG(s), and
   is able to receive data coming from outside of the PMIPv6-Domain
   through LMA and MAG.

   Network-based mobility support for unicast is addressed in [2], while
   multicast support in PMIPv6 is not discussed in it.  This document
   describes PMIPv6 extensions and solutions to support IP multicast
   communication for mobile nodes in PMIPv6-Domain.  The problem
   statements and the requirements for multicast communication in a
   network-based mobility protocol have been documented in [12].  In
   this document, multicast listener mobility is considered, while
   multicast source mobility will be discussed in another draft.

   Functions required on LMA and MAG for multicast communication are
   described in this document.  LMA and MAG set up the bi-directional
   tunnel and set up the forwarding for the mobile node's traffic.  LMA
   must be capable of forwarding multicast packets through MAG toward
   the corresponding mobile nodes.  This condition requires LMA to
   support multicast routing protocols such as Protocol-Independent
   Multicast - Sparse Mode (PIM-SM) [3] and traffic and QoS control if
   needed.  On the other hand, MAG must maintain multicast membership
   status for the attached mobile nodes at the edge and forwards the
   multicast data from LMA to the member nodes.  This condition requires
   MAG to support MLD [4].  Since each mobile node connects MAG with a
   point-to-point access link, scalable operations and extensions for
   MAG must be considered.

   Seamless and fast handover must also be considered.  When a host
   receiving multicast data moves from an access link to another access
   link, the host continuously receives the multicast data through newly
   attached MAG.  The handover procedure should guarantee multicast
   session continuity and avoid extra packet loss and session
   disruption.  Context transfer will be the required function to
   support seamless handover, while its effective procedure should be
   taken into account interaction with multicast communication
   protocols.

   The PMIPv6 extension proposed in this document does not require to
   change unicast communication methods or protocols defined in [2], and
   therefore both unicast and multicast communications for mobile nodes



Asaeda, et al.           Expires April 30, 2009                 [Page 3]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   in PMIPv6-Domain are enabled after all.


















































Asaeda, et al.           Expires April 30, 2009                 [Page 4]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


2.  Conventions and Terminology

2.1.  Conventions Used in This Document

   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 [1].

2.2.  Terminology

   The following terms used in this document are to be interpreted as
   defined in the Proxy Mobile IPv6 specification [2]; Mobile Access
   Gateway (MAG), Local Mobility Anchor (LMA), Mobile Node (MN), Proxy
   Mobile IPv6 Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of
   Address (Proxy-CoA), Mobile Node's Home Network Prefix (MN-HNP),
   Mobile Node Identifier (MN-Identifier), Proxy Binding Update (PBU),
   and Proxy Binding Acknowledgement (PBA).

   As defined in [8], "upstream interface" or "host interface" is an MLD
   proxy device's interface in the direction of the root of the tree.
   Each of an MLD proxy device's interfaces that is not in the direction
   of the root of the tree is called "downstream interface" or "router
   interface".

   The Context Transfer Protocol (CXTP) specification [13] describes the
   mechanism that allows better support for minimizes service disruption
   during handover.  In this document, CXTP is adopted for the multicast
   context transfer protocol in PMIPv6, and "Multicast-Context Transfer
   Data (M-CTD)" is defined as the new terminology for transferring MLD
   state from previously attached MAG (p-MAG) to newly attached MAG
   (n-MAG).

   Mobile Node's Policy Profile includes "multicast channel
   information", whose contents are the same one M-CTD contains, and the
   mandatory fields of the policy profile specified in [2].  MN's Policy
   Profile is provided by "policy store" whose definition is the same as
   of [2], or by CXTP.














Asaeda, et al.           Expires April 30, 2009                 [Page 5]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


3.  Overview

3.1.  Multicast Communication in PMIPv6

   Required components to enable IP multicast are multicast routing
   protocols and host-and-router communication protocols.  This document
   assumes PIM-SM [3] as the multicast routing protocol and MLDv2 [4] or
   LW-MLDv2 [5] as the host-and-router communication protocol.

   The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1.
   LMA and MAG are the core functional entities in PMIPv6-Domain.  The
   entire PMIPv6-Domain appears as a single link from the perspective of
   each mobile node.

                       +---------+
                       | Content |
                       | Source  |
                       +---------+
                            |
                 ***  ***  ***  ***  ***
                *   **   **   **   **   *
               *                         *
                *     Fixed Internet    *
               *                         *
                *   **   **   **   **   *
                 ***  ***  ***  ***  ***
                     /            \
                  +----+        +----+
                  |LMA1|        |LMA2|
                  +----+        +----+
           LMAA1 -> |              | <-- LMAA2
                    |              |
                    \\            //\\
                     \\          //  \\
                      \\        //    \\
                       \\      //      \\
                        \\    //        \\
                         \\  //          \\
             Proxy-CoA1--> |              | <-- Proxy-CoA2
                        +----+          +----+
                        |MAG1|---{MN2}  |MAG2|
                        +----+  |       +----+
                          |     |         |
             MN-HNP1 -->  |   MN-HNP2     |  <-- MN-HNP3, MN-HNP4
                        {MN1}           {MN3}

                    Figure 1: Proxy Mobile IPv6 Domain




Asaeda, et al.           Expires April 30, 2009                 [Page 6]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   When a mobile node wants to subscribe/unsubscribe a multicast
   channel, the node sends MLD Report messages with specifying
   interesting/uninteresting sender and multicast addresses to the
   access link.  The attached MAG detects this membership information
   and transfers the information to the corresponding LMA over a bi-
   directional tunnel when needed, or transfers the information to the
   adjacent multicast router.

   When LMA receives the membership information with MLD Report messages
   or with PIM Join/Prune messages, it coordinates the corresponding
   multicast routing tree if necessary.  This operation requires
   multicast routing protocols or proxy functions for LMA.

   When MAG detects mobile node's handover, it can proceed the seamless
   handover procedures.  Since both PMIPv6 and multicast protocols
   (i.e., MLD and PIM-SM) do not have the functions for handover in the
   original protocol specifications, external functions or protocols
   such as CXTP [13] can be additionally used with PMIPv6 Proxy Binding
   Update (PBU).

3.2.  Protocol Sequence for Joining and Leaving Multicast Channels

   Upon multicast data reception, a mobile node sends MLD Report
   messages including source and multicast addresses.  Although MLDv2
   specification [4] permits to use the unspecified address (::) for a
   host whose interface has not acquired a valid link-local address yet,
   MLDv2 Report messages MUST be sent with a valid IPv6 link-local
   source address in PMIPv6 as defined in [10].  As well, MLDv2 Report
   messages MAY be sent with an IP destination address of FF02:0:0:0:0:
   0:0:16, to which all MLDv2-capable multicast routers listen, but the
   IP unicast address of the attached MAG SHALL be used in many cases as
   explained in [10].

   An MLD proxy [8] can simplify the implementation of multicast data
   forwarding.  By not supporting complicated multicast routing
   protocols, it reduces the implementation cost and the operational
   overhead.  Reducing the operational overhead will also contribute to
   faster routing convergence.  Another advantage is that an MLD proxy
   can be independent of the multicast routing protocol used by the core
   network routers.

   When MAG operates as an MLD proxy and receives MLD Report messages
   from attached mobile nodes, it sends MLD messages on behalf of the
   mobile nodes.  MLD messages are always transferred over pre-
   configured bi-directional tunnels as seen in Figure 2.  MAG operating
   as MLD Proxy always registers "downstream interface (or router
   interface)" upon MLD message reception, but does not send MLD Report
   when the received source and multicast addresses have been already



Asaeda, et al.           Expires April 30, 2009                 [Page 7]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   reported to the same LMA through the same "upstream interface (or
   host interface)".

   MN1        MN2             MAG                 LMA
    |          |               |                   |
    |------MLD Report--------->|                   |
    |     (S1,G1) join         |     MLD Report    |
    |          |               |===bi-dir tunnel==>|
    |          |               |                   |---> PIM (S1,G1) join
    |          |               |                   |
    |          |--MLD Report-->|                   |
    |          | (S2,G2) join  |     MLD Report    |
    |          |               |===bi-dir tunnel==>|
    |          |               |                   |---> PIM (S2,G2) join
    |          |               |                   |
    |          |--MLD Report-->|                   |
    |          | (S1,G1) join  |                   |
    |          |               |                   |

                Figure 2: MLD Report Messages Transmission

   Whether MAG works as an MLD proxy or a PIM-SM router, it MAY store
   multicast channel information reported by attached mobile nodes in
   the MN's policy profile (as defined in [2]).  This information may be
   used by the new MAG during the handover process (see Section 8).


























Asaeda, et al.           Expires April 30, 2009                 [Page 8]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


4.  Local Mobility Anchor Operation

4.1.  LMA Operating As PIM-SM Router

   LMA is responsible for maintaining the mobile node's reachability
   state and is the topological anchor point for the mobile node's home
   network prefix(es).  When LMA acts as a PIM-SM [3] multicast router,
   it serves MAGs as listener nodes.  Each MAG is connected through a
   bi-directional tunnel, and each tunnel end-point address is a Proxy-
   CoA.

   LMA sets up the multicast state and joins the group.  Multicast
   packets are tunneled to MAG that requested to receive the
   corresponding multicast session after being received by the LMA.  The
   MAG forwards these packets to the MN according to the multicast
   listener state in the MAG.

   [TODO: What is the required function for LMA as a multicast router?
   There is a case that a number of mobile nodes, let us say more than
   1,000 nodes, attach MAG and they are listening multicast sessions.
   In addition, these mobile nodes connect to MAG with point-to-point
   links with different prefixes.  This condition will require some
   protocol modification?]

4.2.  LMA Operating As MLD Proxy

   LMA may act as an MLD proxy [8].  When LMA acts as an MLD proxy,
   multicast data is forwarded from outside to mobile nodes through a
   bi-directional tunnel to MAG.

   When LMA acts as an MLD proxy, the attached MAGs must also act as an
   MLD proxy.

4.3.  LMA Operating As AMT Relay

   It is possible for LMA to support AMT [9].  In this case, LMA acts as
   an AMT Relay and the attached MAGs must act as AMT Gateways.  When
   LMA acts as an AMT Relay, it MUST also work as a PIM-SM router.













Asaeda, et al.           Expires April 30, 2009                 [Page 9]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


5.  Mobile Access Gateway Operation

   The mobile access gateway (MAG) is the entity that performs the
   mobility management on behalf of a mobile node.  MAG is responsible
   for detecting the mobile node's movements to and from the access
   link.

5.1.  MAG Operating As MLD Proxy

   [2] supports only point-to-point access link types for MAG and MN
   connection; hence MN and MAG are the only two nodes on an access
   link, where the link is assumed to be multicast capable.  Since MAG
   will deal with mobile nodes' membership states reported by a large
   number of the downstream mobile nodes with MLD Report messages, the
   protocol scalability must be taken into account.

   MAG acting as an MLD proxy sends MLD Query messages to all or some of
   attached mobile nodes as described in [10].  After MAG receives MLD
   Report messages from the mobile nodes, it forwards the MLD Report
   messages on behalf of these mobile nodes to LMA.  Mobile nodes send
   MLD messages with their link-local address to MAG, and MAG forwards
   the MLD messages through the bi-directional tunnel to LMA with the
   MAG's link-local address.

   An MLD proxy requires that the upstream and downstream interfaces
   must be statistically configured.  As well, MAG MUST configure an
   upstream interface that is the interface MLD Report messages are sent
   to LMA and downstream interfaces that are the interfaces MLD Report
   messages are received from mobile nodes.

5.2.  MAG Operating As AMT Gateway

   It is possible for MN and MAG to perform with AMT [9].  In this case,
   MAG acts as an AMT Gateway.  MAG then summarizes all downstream
   membership states.  Since AMT data message that is a UDP packet
   encapsulating IP multicast data is transmitted as a regular unicast
   packet, the AMT data is not transmitted through a bi-directional
   tunnel between MAG and LMA but forwarded toward the LMA by hop-by-hop
   manner.

   When MAG acts as an AMT Gateway, it SHOULD also work as an MLD Proxy
   as specified in [9].

5.3.  MAG Operating As Multicast Router

   The optimal multicast routing path does not always include LMA,
   especially in local routing described in [12].  The local routing
   option is designed to support node-to-node communication within



Asaeda, et al.           Expires April 30, 2009                [Page 10]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   PMIPv6-Domain where a local content source exists.

   When LMA is not on a multicast delivery tree, MAG runs multicast
   routing protocols to attach the optimal multicast routing path.  This
   document assume use of PIM-SM [3] as the supported multicast routing
   protocol.

   Because of its implementation or operational costs, operators may not
   want to support PIM-SM on MAG.  However, an MLD proxy requires to
   statically configure its upstream interface, which is a bi-
   directional tunnel as specified in Section 5.1, to receive all
   multicast data, because there is no method to dynamically change the
   upstream interface.  Therefore, if operators need to take into
   account the case that an upstream interface for the optimized
   multicast path is NOT a bi-directional tunnel to LMA but other
   interface, and want MAG to "select" optimized routing path, MAG must
   act as a PIM-SM router.


































Asaeda, et al.           Expires April 30, 2009                [Page 11]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


6.  Mobile Node Operation

   Mobile nodes attached to MAG can behave as the regular receiver
   hosts.  A mobile node sends MLD messages to MAG when it wants to
   subscribe and unsubscribe IP multicast channels.  And mobile nodes do
   not change their behaviors whether MAG is acting as an MLD proxy or
   an AMT Gateway.  All MLD related considerations are described in
   [10], which will give some advantage for its resource saving and
   seamless handover for PMIPv6 multicast.

   [2] allows a mobile node is a router.  In this document, MN may
   behave as an MLD proxy [8] when MN is working as a unicast router.

   [TODO: What is the other function for MN needed?  Any specific
   requirement?]




































Asaeda, et al.           Expires April 30, 2009                [Page 12]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


7.  Dual-Mode Implementation

   Operators may want to make LMA or MAG act as both an MLD proxy and a
   PIM-SM multicast router to support different customers.  This
   document proposes a "dual-mode" implementation that enables LMA or
   MAG to support both an MLD proxy function and a multicast routing
   function simultaneously.

   To simplify mobile node's handover procedure among dual-mode MAGs,
   p-MAG and n-MAG should not change the behaviors for the same mobile
   node.  For instance, in dual-mode, if p-MAG that a mobile node
   attaches is working as MLD proxy, n-MAG that the mobile node will
   attach must also work as an MLD proxy.  It is same as of PIM-SM.






































Asaeda, et al.           Expires April 30, 2009                [Page 13]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


8.  Handover Process

   MAG is responsible for detecting the mobile node's movements to and
   from the access link and for initiating binding registrations to the
   mobile node's LMA.  MAG tracks the mobile node's movements to and
   from the access link and for signaling the mobile node's LMA.  In
   PMIPv6, it SHOULD not require for mobile nodes to initiate to re-
   subscribe multicast channels, and MAG SHOULD keep multicast channel
   subscription status for mobile nodes even if they attach a different
   MAG in PMIPv6-Domain.  In this section, mobility handover procedures
   are described.

8.1.  MAG Operating As MLD Proxy

   When MAG operates as an MLD proxy, there are two possible ways to
   proceed MLD listener handover; MLD listener handover with CXTP and
   MLD listener handover with MN's Policy Profile.  A Proxy Binding
   Update with multicast extension (PBU-M) (defined in Section 8.4) is
   always used to request the LMA to forward multicast data.

   The MLD listener handover with CXTP shown in Figure 3 is defined as
   follows;

   1.   Whenever MN attaches to n-MAG, the n-MAG requests multicast
        context transfer to p-MAG.

   2.   p-MAG provides the multicast states corresponding to the moving
        MN-Identifier to n-MAG. p-MAG utilizes a context transfer
        protocol to deliver MN's profile to n-MAG, and sends Multicast
        Context Transfer Data (M-CTD) (defined in Section 8.3) to n-MAG.

   3.   n-MAG records MN's profile including multicast channel
        information.

   4.   n-MAG subscribes multicast channel on behalf of MN.  PBU-M is
        transmitted to LMA to establish a bi-directional tunnel for
        forwarding corresponding multicast data.














Asaeda, et al.           Expires April 30, 2009                [Page 14]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


      MN           p-MAG           n-MAG                LMA
       |             |               |                   |
       |-MLD Report->|             MLD Report            |
       |             |===========bi-dir tunnel==========>|
       |             |               |                   |---> PIM join
       |             |          Multicast data           |
       |<------------|<==========bi-dir tunnel===========|
       |             |               |                   |
     Detach          |               |                   |
       |             |               |                   |
     Attach          |               |                   |
       |             |               |                   |
       |------------RS-------------->|                   |
       |             |<---CT-Req-----|                   |
       |             |               |                   |
       |             |-----CXTP----->|                   |
       |             |     M-CTD     |     MLD Report    |
       |             |               |-------PBU-M------>|
       |             |               |                   |
       |             |               |<-------PBA--------|
       |             |               |                   |
       |<-----------RA---------------|                   |
       |             |               |                   |
       |             |               |  Multicast data   |
       |<----------------------------|<==bi-dir tunnel===|
       |             |               |                   |
       |<---------MLD Query----------|     MLD Report    |
       |----------MLD Report-------->|===bi-dir tunnel==>|
       |             |               |                   |

                 Figure 3: MLD listener handover with CXTP

   After MN attaches to n-MAG, the multicast data will be delivered to
   the MN immediately.  MN's multicast membership state is maintained
   with MLD Query and Report messages exchanged by MN and n-MAG.

   Mobile node's multicast state is kept in MN's profile.  If MN's
   policy profile is stored in a policy store [2], it is not necessary
   to use a context transfer protocol between p-MAG and n-MAG.  In such
   a case, n-MAG obtains MN's mulicast state by the same mechanism used
   to acquire MN-ID and profile during MN's attachment process [2].

   The procedure for MLD listener handover with MN's Policy Profile
   (Figure 4) is shown as follows;







Asaeda, et al.           Expires April 30, 2009                [Page 15]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   1.   n-MAG obtains the MN-Identifier and learns multicast channel
        information described in Mobile Node's Policy Profile associated
        to this MN-Identifier.

   2.   n-MAG prepares the PBU-M that includes multicast channel
        information the MN has subscribed.

   3.   n-MAG transmits PBU-M to LMA to establish a bi-directional
        tunnel for forwarding corresponding multicast data.

   4.   LMA forwards requested multicast data through a bi-directional
        tunnel between the LMA and n-MAG.


      MN           p-MAG           n-MAG                LMA
       |             |               |                   |
       |-MLD Report->|             MLD Report            |
       |             |===========bi-dir tunnel==========>|
       |             |               |                   |---> PIM join
       |             |          Multicast data           |
       |<------------|<==========bi-dir tunnel===========|
       |             |               |                   |
     Detach          |               |                   |
       |             |               |                   |
     Attach          |        MN attachment event        |
       |             |    (Acquire MN-Id and Profile)    |
       |             |               |                   |
       |------------RS-------------->|                   |
       |             |               |     MLD Report    |
       |             |               |-------PBU-M------>|
       |             |               |                   |
       |             |               |<-------PBA--------|
       |             |               |                   |
       |<-----------RA---------------|                   |
       |             |               |                   |
       |             |               |  Multicast data   |
       |<----------------------------|<==bi-dir tunnel===|
       |             |               |                   |
       |<---------MLD Query----------|     MLD Report    |
       |----------MLD Report-------->|===bi-dir tunnel==>|
       |             |               |                   |

         Figure 4: MLD listener handover with MN's Policy Profile








Asaeda, et al.           Expires April 30, 2009                [Page 16]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


8.2.  MAG Operating As Multicast Router

   MAG operating PIM-SM multicast routing protocol joins the multicast
   delivery tree when an attached mobile node subscribes a multicast
   channel.  In order to reduce handover latency, LMA forwards multicast
   data to n-MAG until n-MAG has joined the multicast delivery tree.  A
   Proxy Binding Update with multicast extension (PBU-M) is always used
   to request the LMA to forward multicast data.

   When MAG operates PIM-SM routing protocol, leveraging CXTP is the
   possible handover scenario as in the following procedure;

   1.   Whenever MN attaches to n-MAG, the n-MAG requests multicast
        context transfer to p-MAG.

   2.   p-MAG provides the multicast states corresponding to the moving
        MN-Identifier to n-MAG. p-MAG utilizes a context transfer
        protocol to deliver MN's profile to n-MAG, and sends M-CTD to
        n-MAG.

   3.   n-MAG initiates the process to subscribe the multicast channels.

   4.   n-MAG requests LMA to forward multicast data in the meantime.
        n-MAG prepares the PBU-M that includes multicast channel
        information the MN has subscribed and has not yet received at
        n-MAG.

   5.   LMA forwards requested multicast data through a bi-directional
        tunnel between the LMA and n-MAG.

   6.   Whenever n-MAG joins the multicast delivery tree, it notifies
        the LMA to stop forwarding the data and switches to the optimal
        multicast routing path.


















Asaeda, et al.           Expires April 30, 2009                [Page 17]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


     MN            p-MAG           n-MAG                LMA
      |              |               |                   |
      |--MLD Report->|               |                   |
      |              |               |                   |
      |              |---> PIM join  |                   |
      |              |               |                   |
      |<--Multicast--|               |                   |
      |     data     |               |                   |
    Detach           |               |                   |
      |              |               |                   |
    Attach           |               |                   |
      |              |               |                   |
      |-------------RS-------------->|                   |
      |              |               |                   |
      |              |<---CT-Req-----|                   |
      |              |               |                   |
      |              |-----CXTP----->|                   |
      |              |     M-CTD     |---> PIM join      |
      |              |               |                   |
      |              |               | MLD Report (join) |
      |              |               |-------PBU-M------>|
      |              |               |                   |---> PIM join
      |              |               |<-------PBA--------|
      |              |               |                   |
      |<------------RA---------------|                   |
      |              |               |                   |
      |              |               |  Multicast data   |
      |              |               |<==bi-dir tunnel===|
      |<-------Multicast data--------|                   |
      |              |               |                   |
      |              |      Join process completed       |
      |              |               |                   |
      |              |               | MLD Report (leave)|
      |              |               |-------PBU-M------>|
      |              |               |                   |---> PIM prune
      |<-------Multicast data--------|                   |
      |              |               |                   |

                    Figure 5: PIM-SM handover with CXTP

   The following procedure is for PIM-SM handover using MN's Policy
   Profile;

   1.   When n-MAG detects a moving mobile node, it obtains the MN-
        Identifier and learns multicast channel information described in
        Mobile Node's Policy Profile associated to this MN-Identifier.





Asaeda, et al.           Expires April 30, 2009                [Page 18]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   2.   n-MAG prepares the PBU-M that includes multicast channel
        information the MN has subscribed and has not yet received at
        n-MAG.

   3.   n-MAG transmits PBU-M to LMA to establish a bi-directional
        tunnel for forwarding corresponding multicast data.

   4.   LMA subscribes requested multicast channels and forwards the
        data through a bi-directional tunnel between the LMA and n-MAG.

   5.   Whenever n-MAG joins the multicast delivery tree, it notifies
        the LMA to stop forwarding the data and switches to the optimal
        multicast routing path.






































Asaeda, et al.           Expires April 30, 2009                [Page 19]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


     MN            p-MAG           n-MAG                LMA
      |              |               |                   |
      |--MLD Report->|               |                   |
      |              |               |                   |
      |              |---> PIM join  |                   |
      |              |               |                   |
      |<--Multicast--|               |                   |
      |     data     |               |                   |
      |              |               |                   |
    Detach           |               |                   |
      |              |               |                   |
    Attach           |        MN attachment event        |
      |              |    (Acquire MN-Id and Profile)    |
      |-------------RS-------------->|                   |
      |              |               |---> PIM join      |
      |              |               |                   |
      |              |               | MLD Report (join) |
      |              |               |-------PBU-M------>|
      |              |               |                   |---> PIM join
      |              |               |<-------PBA--------|
      |              |               |                   |
      |<------------RA---------------|                   |
      |              |               |                   |
      |              |               |   Multicast data  |
      |              |               |<==bi-dir tunnel===|
      |<-------Multicast data--------|                   |
      |              |               |                   |
      |              |      Join process completed       |
      |              |               |                   |
      |              |               | MLD Report (leave)|
      |              |               |-------PBU-M------>|
      |              |               |                   |---> PIM prune
      |<-------Multicast data--------|                   |
      |              |               |                   |

            Figure 6: PIM-SM handover with MN's Policy Profile

8.3.  Multicast Context Transfer Data Format

   The following information is necessary to keep mobile node's
   membership status, and hence M-CTD includes the information;

   1.   Receiver address - indicates an address of a receiver host
        sending the Current-State Report.







Asaeda, et al.           Expires April 30, 2009                [Page 20]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   2.   Last membership report - indicates the time that the router
        receives the last Current-State Report.

   3.   Filter mode - indicates either INCLUDE or EXCLUDE as defined in
        [4].

   4.   Source addresses and multicast address - indicates the address
        pair that the receiver has joined.

8.4.  Proxy Binding Update with Multicast Extension

     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|C|   Reserved    |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 7: Proxy Binding Update Message with Multicast Extension

   A Binding Update message that is sent by MAG to LMA is referred to as
   the "Proxy Binding Update" message.  A new flag (C) is included in
   the Binding Update message with multicast extension.  The rest of the
   Binding Update message format remains the same as defined in [11] and
   with the additional (R), (M), and (P) flags, as specified in [14],
   [15], and [2], respectively.

      Multicast Channel Subscription Flag

      A new flag (C) is included in the Binding Update message to
      indicate to LMA that the Binding Update message is a multicast
      channel subscription.

   When (C) flag is specified in PBU-M message, the mobility options
   field includes the same information of MLDv2 Report message [4]:









Asaeda, et al.           Expires April 30, 2009                [Page 21]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


      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 = 143   |    Reserved   |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Reserved            |Nr of Mcast Address Records (M)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                  Multicast Address Record [1]                 .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                  Multicast Address Record [2]                 .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
     .                               .                               .
     |                               .                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                  Multicast Address Record [M]                 .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 8

   Each Multicast Address Record has the following internal format:


















Asaeda, et al.           Expires April 30, 2009                [Page 22]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Multicast Address                       *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Source Address [1]                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-                                                             -+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Source Address [2]                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-                                                             -+
     .                               .                               .
     .                               .                               .
     .                               .                               .
     +-                                                             -+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Source Address [N]                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                         Auxiliary Data                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 9




Asaeda, et al.           Expires April 30, 2009                [Page 23]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


   All the above fields contain data with the same definitions in [4].


















































Asaeda, et al.           Expires April 30, 2009                [Page 24]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


9.  IPv4-Only and Dual-Stack Node Support

   The mobile node may be an IPv4-only node, IPv6-only node, or a dual-
   stack (IPv4/v6) node.  Although this document mainly describes IPv6
   address/prefix mobility with the transport network being IPv6, it
   proposes the tunneling method by which IPv4-only mobile node or a
   dual-stack mobile node that wants to subscribe IPv4 multicast
   channels.  As with the discussion in the MBONE working group, AMT [9]
   is the possible candidate to fulfill the requirement.  AMT provides
   the multicast connectivity to the unicast-only inter-network.  To do
   this, multicast packets being sent to or from a site are encapsulated
   in unicast packets.

   When MAG behaves as an AMT Gateway, it sends an MLD report message
   via its AMT Pseudo-Interface that encapsulates the message to a
   particular AMT Relay (i.e., LMA).

   While MLD messages or multicast packets are always encapsulated with
   both IPv4 and IPv6 headers, AMT messages, which are the regular IPv6
   unicast packets, are not transmitted over a bi-directional tunnel.































Asaeda, et al.           Expires April 30, 2009                [Page 25]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


10.  IANA Considerations

   This document does not require any IANA action.
















































Asaeda, et al.           Expires April 30, 2009                [Page 26]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


11.  Security Considerations

   TBD.
















































Asaeda, et al.           Expires April 30, 2009                [Page 27]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


12.  Acknowledgements

   Many of the specifications described in this document are discussed
   and provided by the PMIPv6 multicast support design team members.















































Asaeda, et al.           Expires April 30, 2009                [Page 28]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


13.  References

13.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to indicate requirement
         levels", RFC 2119, March 1997.

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

   [3]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
         "Protocol Independent Multicast - Sparse Mode (PIM-SM):
         Protocol Specification (Revised)", RFC 4601, August 2006.

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

   [5]   Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
         Protocols",
         draft-ietf-mboned-lightweight-igmpv3-mldv2-04.txt (work in
         progress), September 2008.

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

   [7]   Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
         RFC 4607, August 2006.

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

   [9]   Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
         Pusateri, "Automatic IP Multicast Without Explicit Tunnels
         (AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in
         progress), October 2007.

   [10]  Asaeda, H. and T. Schmidt, "IGMP and MLD Extensions for Mobile
         Hosts and Routers",
         draft-asaeda-multimob-igmp-mld-mobility-extensions-01.txt (work
         in progress), August 2008.

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

   [12]  Deng, H., Schmidt, T., Seite, P., and P. Yang, "Multicast
         Support Requirements for Proxy Mobile IPv6",



Asaeda, et al.           Expires April 30, 2009                [Page 29]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


         draft-deng-multimob-pmip6-requirement-01.txt (work in
         progress), October 2008.

   [13]  Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli,
         "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.

13.2.  Informative References

   [14]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [15]  Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
         "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
         RFC 4140, August 2005.




































Asaeda, et al.           Expires April 30, 2009                [Page 30]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


Authors' Addresses

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Email: asaeda@wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~asaeda/


   Pierrick Seite
   France Telecom
   4, rue du Clos Courtel
   BP 91226, Cesson-Sevigne  35512
   France

   Email: pierrick.seite@orange-ftgroup.com


   Jinwei Xia
   Huawei Technologies Co., Ltd.
   Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Email: xiajinwei@huawei.com






















Asaeda, et al.           Expires April 30, 2009                [Page 31]


Internet-Draft       PMIPv6 Extensions for Multicast        October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Asaeda, et al.           Expires April 30, 2009                [Page 32]