Skip to main content

Routes Optimization for PMIPv6 Multicast
draft-liu-multimob-pmipv6-multicast-ro-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Juan Liu , Wen Luo , Wei Yan
Last updated 2012-01-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-multimob-pmipv6-multicast-ro-00
MULTIMOB Working Group                                            J. Liu
Internet-Draft                                                    W. Luo
Intended status: Standards Track                                  W. Yan
Expires: August 3, 2012                                  ZTE Corporation
                                                        January 31, 2012

                Routes Optimization for PMIPv6 Multicast
               draft-liu-multimob-pmipv6-multicast-ro-00

Abstract

   To support IP multicasting in PMIPv6 domain, MULTIMOB WG has issued
   several proposals including the base solution,dedicated schemes and
   direct routing which requires all communications to go through the
   local mobility anchor(LMA),the dedicated server and the native
   multicasting infrastructure ,respectively.  As this can be
   suboptimal, localized routing (LR) allows multicast source attached
   to the same or different mobile access gateways(MAG) with mobile node
   to send multicast data by using localized forwarding or a direct
   tunnel between the gateways without any dedicated devices or
   dependence of the native multicasting infrastructure.  This document
   describes multicast routes optimazition mechanisms for localized
   routing.The MAG and the LMA are the mobility entities defined in the
   PMIPv6 protocol and act as PIM-SM routers.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 3, 2012.

Copyright Notice

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

Liu, et al.              Expires August 3, 2012                 [Page 1]
Internet-Draft           RELOAD Client Extension            January 2012

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Add Route to MRIB  . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Optimized Multicast Route Establishment  . . . . . . . . .  7
     4.3.  Optimized Multicast Route Deletion . . . . . . . . . . . .  9
   5.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . . 11
   6.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . . 11
   7.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 12
   8.  Message Format Extension . . . . . . . . . . . . . . . . . . . 12
     8.1.  Proxy Binding Update with Source Address Finding
           Extension  . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.2.  Proxy Binding Acknowledgement Message with Source
           Address Finding Extension  . . . . . . . . . . . . . . . . 13
     8.3.  Care-of Address Option . . . . . . . . . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Liu, et al.              Expires August 3, 2012                 [Page 2]
Internet-Draft           RELOAD Client Extension            January 2012

1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] 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 an MN.  An 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 [RFC5213],
   while multicast support in PMIPv6 is not discussed in it.  Since LMA
   and MAG set up a bi-directional IPv6-in-IPv6 tunnel for each mobile
   node and forwards all mobile node's traffic according to [RFC5213],
   it highly wastes network resources when a large number of mobile
   nodes join/ subscribe the same multicast sessions/channels, because
   independent data copies of the same multicast packet are delivered to
   the subscriber nodes in a unicast manner through MAG.

   In order to deploy the multicast service in the PMIPv6 network, many
   schemes have been proposed:

   The base solution described in [RFC6224] provides options for
   deploying multicast listener functions in PMIPv6-Domains without
   modifying mobility and multicast protocol standards.  However, in
   this specification, MAG MUST act as an MLD proxy [RFC4605] and hence
   MUST dedicate a tunnel link between LMA and MAG to an upstream
   interface for all multicast traffic.  It requires all the LMA to
   forward multicast packets to MAG via PMIPv6 tunnel which can be
   suboptimal.

   [draft-zuniga-multimob-pmipv6-ropt-01]uses a multicast tree mobility
   anchor(MTMA) as the topological anchor point for multicast traffic,
   as well as a direct routing option where the MAG can provide access
   to multicast content in the local network.All the multicast traffic
   has to go through the MAG-MTMA tunnel which result in suboptimal
   multicast routing path like the base solution.And the direct routing
   solution needs native multicasting infrastructure as a requirement

   [draft-asaeda-multimob-pmip6-extension-07]describes PMIPv6 extensions
   to support IP multicast communication for mobile nodes in PMIPv6-
   Domain.If the LMA is the upstream router for the channel(s) for the
   MAG, the MAG encapsulates PIM Join/Prune messages using the LMA-MAG
   bi-directional tunnel.  The multicast data has to always go through
   the LMA-MAG bi-directional tunnel.It does solve the tunnel
   convergence problem and source mobility,But when multicast source is

Liu, et al.              Expires August 3, 2012                 [Page 3]
Internet-Draft           RELOAD Client Extension            January 2012

   a mobile node in the same PMIPv6 domain,using the proposed scheme
   mentioned above, the routing path through a multicast anchor(LMA)
   tends to be longer,which results in non-optimal multicast routes and
   performance degradation.Figure 1 shows the Architecture of Multicast
   Deployment with listener and source in the same PMIPv6 domain,LMA
   will receive all multicast traffic originating from its associated
   MN-S through LMA-MAG2 bi-directional tunnel,and then forward to
   multicast listener MN through LMA-MAG1 bi-directional tunnel,causing
   non-optimal multicast routes.

                                Internet
                                    :
                                    |
                                    |
                                 +-----+
                                 | LMA |   Multicast Anchor
                                 +-----+
                                    ||
                                   //\\
                                  //  \\
                                 //    \\
                                //      \\
                               //        \\
                              //          \\
                             ||            ||
                           +----+        +----+
                           |MAG1|        |MAG2|
                           +----+        +----+
                             |              |
                             |              |
                          +----+          +----+
                          | MN |          |MN-S|
                          +----+          +----+
                Multicast Listener(s)     Multicast Sender(s)

   Figure1 Architecture of Multicast Deployment with listener and source
                         in the same PMIPv6 domain

   In this document, we discuss how to establish optimized multicast
   routes for the deployment scenario provided by Figure 1.  The
   proposed protocol assumes that both LMA and MAG enable the Protocol-
   Independent Multicast - Sparse Mode (PIM-SM) multicast routing
   protocol [RFC4601],and further MAG MUST operate as an "SSM-aware"
   router [RFC4604].  The proposed protocol supports seamless handover.
   It can cooperate with local routing and direct routing to deliver IP
   multicast packets for mobile nodes and source mobility.  In this
   document, because multicast localized routing is mainly focused on,
   the detail specification of source mobility and is not described.

Liu, et al.              Expires August 3, 2012                 [Page 4]
Internet-Draft           RELOAD Client Extension            January 2012

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 following terms used in this document are to be interpreted as
   defined in [RFC5213]; Home Address(HoA),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), Proxy Binding Update (PBU), and Proxy Binding
   Acknowledgement (PBA).

   Terms DR(Designated Router),MRIB(Multicast Routing Information
   Base),RPF(Reverse Path Forwarding),RPF Neighbor,SPT(shortest-path
   tree),PIM Join,Pim Prune,iif(incoming interface),oiflist(outgoing
   interface list),Source-Specific Multicast(SSM) are to be interpreted
   as defined in[RFC4601]

3.  Overview

   In the SSM case, the multicast receivers actively send the (HoA,G)
   subscribe message, for the LMA is just the topological anchor point
   of the source's Home Address (HoA) in the PMIPv6 network.

Liu, et al.              Expires August 3, 2012                 [Page 5]
Internet-Draft           RELOAD Client Extension            January 2012

                                 Internet
                                     :
                                     |
                                     |
                                  +-----+
                                  | LMA |      Unicast Anchor
                                  +-----+
                                     ||
                                   //  \\
                                 //      \\
                               //          \\  Unicast Tunnel
                             //              \\
                           //                  \\
                         //                      \\
                        ||                        ||
                      +----+                    +----+
                      |MAG1|=O=O=O=O=O=O=O=O=O=O|MAG2|
                      +----+                    +----+
                        |     Multicast Tunnel     |
                        |                          |
                     +----+                      +----+
                     | MN |                      |MN-S|
                     +----+                      +----+
             Multicast Listener(s)          Multicast Sender(s)

            Figure2 Architecture of Optimized Multicast Routing

   As shown in Figure 2, MN(the multicast receivers) and MN-S(the
   multicast senders) are both mobile nodes in the same PMIPv6
   domain,they both have binding cache entry in the LMA.  MN sends
   (HoA,G) subscribe message(MLD Report messages) specifying sender and
   multicast addresses to the access link to establish the SPT,the MN
   has to operate as an "SSM-aware" host [RFC4604] .  On receiving the
   (HoA,G) subscribe message from the MN,the attached MAG1 sends a PBU-F
   message to LMA to find the CoA (i. e., IP address of MAG2) of MN-S.
   On the reception of PBU-F, the LMA responds with a PBA-F message
   including the CoA of MN-S to MAG1, after lookup of its binding cache
   entry.  After acquiring the CoA of MN-S,MAG1 establishes bi-
   directional tunnel with MAG2,and sends PIM Join message to MAG2
   through this tunnel,MAG1 and MAG2 establish the ralated muticast
   state for MN.So the MAG-based SPT is established successfully and the
   subsequent multicast data flow will be transmitted through the MAG-
   based SPT which is represented by "=O" in Figure 2.Unicast data flow
   will be transmitted through base PMIPv6 tunnel which is represented
   by "||" in Figure 2.

   The tunnel between MAG1 and MAG2 is used for multicast
   packets(including signaling and data flow) transmission only.

Liu, et al.              Expires August 3, 2012                 [Page 6]
Internet-Draft           RELOAD Client Extension            January 2012

   As described in [RFC4601], on receipt of data from S to G on
   interface iif (incoming interface of the packet), the DR will firstly
   check whether the source is directly connected and the iif is
   identical to the Reverse Path Forwarding (RPF) interface.  As shown
   in Figure 2 ,MAG2 is the DR of MN-S,MAG1 is the DR of MN.After tunnel
   establishment between MAG1 and MAG2, MAG1 add the tunnel route to the
   MRIB,the RPF check will be successful.

   this draft considers that every MN demanding multicast-only services
   is previously registered in a PMIPv6 unicast domain to get a unicast
   IP address.

4.  Protocol Operation

4.1.  Add Route to MRIB

   In PIM-SM, the MRIB is used to decide where to send Join/Prune
   messages. on receiving the MLD Report message from MN,the MAG of MN
   has to choose a RPF Neighbor that the MRIB indicates should be used
   to forward packets to,and then send the Join/Prune message to the RPF
   Neighbor.

   After tunnel establishment between MAG1 and MAG2, MAG1 add the tunnel
   route to the MRIB,so the RPF Neighbor of MAG1 is MAG2,MAG1 send PIM
   Join/Prune message through this tunnel.

   Once the multicast subscription information is retrieved from the
   pMAG, the LMA encapsulates it in the PBA message by using the TLV
   option "Active Multicast Subscription", and forwards the PBA message
   to the nMAG.  Then, the nMAG can subscribe the multicast flow on
   behalf of the MN, if there is no other MN receiving it already at the
   nMAG."

   When the MAG is connected with other PIM-SM router not over LMA,
   there's no problem.  PIM-SM establishes multicast routing path using
   RPF algorithm through reflecting MAG's RIB.

   But when the MAG is connected with several LMAs including PIM-SM,
   MRIB SHOULD get information from PMIP routing table but "MAG's RIB
   doesn't reflect PMIP routing" (Thomas and Hitoshi agreed it).

4.2.  Optimized Multicast Route Establishment

   This document provides the multicast routes optimization scheme.The
   procedures are described as follows and illustrated in Figure 3;

Liu, et al.              Expires August 3, 2012                 [Page 7]
Internet-Draft           RELOAD Client Extension            January 2012

        MN            MAG1                 LMA     MN-S       MAG2
         |              |                   |        |          |
         |--MLD Report->|                   |        |          |
         |  (S,G) join  |                            |          |
         |              |------PBU-F------->|        |          |
         |              |                   |        |          |
         |              |<------PBA-F-------|        |          |
         |              |Acquire CoA of MN-S|        |          |
         |              |                   |        |          |
         |              |                   |        |          |
         |              |                   |        |          |
         |              |<=====================================>|
         |              |   Establish multicast Bi-dir tunnel   |
         |              |                   |        |          |
         |              |                   |        |          |
         |      Add route to MRIB           |        |          |
         |              |                   |        |          |
         |              |                   |        |          |
         |              |                   |        |          |
         |      Update (S,G) state          |        |          |
         |           Set iif                |        |          |
         |              |                   |        |          |
         |              |                   |        |          |
         |              |             PIM (S,G) join |          |
         |              |=============Bi-dir tunnel============>|
         |              |                   |        |          |
         |              |                   |        |          |
         |              |                   |        |Update (S,G) state
         |              |                   |        |   Set oiflist
         |              |                   |        |          |
         |              |                   |       Multicast data
         |              |                   |        |--------->|
         |              |             Multicast data |          |
         |Multicast data|<============Bi-dir tunnel=============|
         |<-------------|                   |        |          |

             Figure3 Procedure of establishing multicast Route

   1.MN sends (HoA,G) subscribe message(MLD Report messages) specifying
   sender and multicast addresses to the access link.

   2.On receiving the (HoA,G) subscribe message from the MN,the attached
   MAG1 sends a PBU-F message to LMA to find the CoA (i. e., IP address
   of MAG2) of MN-S.

   3.On the reception of PBU-F, the LMA responds with a PBA-F message
   including the CoA of MN-S to MAG1, after lookup of its binding cache
   entry.

Liu, et al.              Expires August 3, 2012                 [Page 8]
Internet-Draft           RELOAD Client Extension            January 2012

   4.After acquire the CoA of MN-S,MAG1 establish bi-directional tunnel
   with MAG2.Refer to [RFC5213] for the detailed tunnel negotiation
   mechanism.

   5.After tunnel establishment,MAG1 add the tunnel route to the MRIB,so
   the RPF Neighbor of MAG1 is MAG2.

   6.If there are multicast channels the MN has subscribed but MAG1 has
   not yet subscribed, MAG1 establishes multicast state for MN,and sets
   the iif of the multicast state as MAG1-MAG2 tunnel interface.if MAG1
   already subscribed the channel,MAG1 updates the iif of the multicast
   state as MAG1-MAG2 tunnel interface.

   7.MAG1 joins the corresponding multicast channels by sending the PIM
   Join message to the RPF Neighbor MAG2 through the MAG1-MAG2 tunnel.

   8.On the reception of PIM Join message from MAG1,If MAG2 has not yet
   subscribed the multicast channel ,MAG2 establishes multicast state
   for the channel,and adds the MAG2-MAG1 tunnel interface to the
   oiflist of the multicast state .if MAG2 already subscribed the
   channel,MAG2 updates the oiflist of the multicast state by adding the
   MAG2-MAG1 tunnel interface to the oiflist.

   9.The subsequent multicast data flow will be transmitted through the
   optimized multicast route(MAG1-MAG2 bi-directional tunnel).

4.3.  Optimized Multicast Route Deletion

Liu, et al.              Expires August 3, 2012                 [Page 9]
Internet-Draft           RELOAD Client Extension            January 2012

        MN            MAG1                                    MAG2
         |              |                                       |
         |--MLD Report->|                                       |
         | leave (S,G)  |                                       |
         |              |                                       |
         |              |                                       |
         |With regard to MN-S,MN is the                         |
         |last multicast listener on MAG1                       |
         |              |                                       |
         |              |                                       |
         |              |                                       |
         | delete all the (S,G) state                           |
         |  ralating to MN-S on MAG1                            |
         |              |                                       |
         |              |                                       |
         |              |                                       |
         |              |                                       |
         |              |             PIM (S,G) prune           |
         |              |=============Bi-dir tunnel============>|
         |              |                                       |
         |              |                                       |
         |              |                                       |
         |              |                             update (S,G) state
         |              |                             update oiflist
         |              |                                       |
         |              |     Remove multicast Bi-dir tunnel    |
         |              |<======================================|
         |              |                                       |

               Figure4 Procedure of deleting multicast Route

   1.MN sends (HoA,G) leave message(MLD Report messages) specifying
   sender and multicast addresses to the access link.

   2.On receiving the (HoA,G) leave message from the MN,if MAG1 figure
   that MN is the last multicast listener subscribed to the MN-S,MAG1
   perform the following steps,otherwise,MAG1 simply delete the
   multicast state of MN as normal.

   3.MAG1 delete all the multicast state related to MN-S.

   4.MAG1 remove the tunnel route from the MRIB and leave the
   corresponding multicast channels by sending the PIM Prune message to
   the RPF Neighbor MAG2 through the MAG1-MAG2 tunnel.

   5.On the reception of PIM Prune message from MAG1,,MAG2 updates the
   oiflist of the multicast state by removing the MAG2-MAG1 tunnel
   interface from the oiflist.

Liu, et al.              Expires August 3, 2012                [Page 10]
Internet-Draft           RELOAD Client Extension            January 2012

   6.Remove bi-directional tunnel between MAG1 and MAG2.Refer to
   [RFC5213] for the detailed tunnel negotiation mechanism.

5.  Local Mobility Anchor Operation

   On receiving a PBU-F message from MAG, the LMA must perform the
   following operations.

   1.  Check if the PBU-F message contains the F flag set to 1.

   2.  Find the CoA of MN-S by looking up the binding cache of LMA.

   3.  If the corresponding HoA-CoA entry is found in the binding cache,
   LMA will respond to MAG of MN with a PBA-F message containing a
   success indication.  Otherwise, if not found, LMA will respond with
   the PBA-F containing a failure indication.

   The responding PBA-F message from LMA to MAG of MN is constructed as
   follows.

   1.  Source address field in the IP header must be set to IP address
   of LMA

   2.  Destination address filed in the IP header must be set to IP
   address of the MAG of MN

   3.  The PBA message MUST include the CoA of MN-S.

6.  Mobile Access Gateway Operation

   The MAG MUST operate as an "SSM-aware" router.  [RFC4604] provide the
   behavior of an "SSM-aware" router.

   The PBU-F message from MAG to LMA MUST be constructed, as specified
   below.

   1.  Source address field in the IP header must contain the IP address
   of MAG.

   2.  Destination address filed in the IP header must contain the IP
   address of LMA.

   3.  The PBU-F message must include the HoA of MN-S.

   On receiving a PBA-F message from LMA, MAG1(MAG of MN) MUST perform
   the following operations.

Liu, et al.              Expires August 3, 2012                [Page 11]
Internet-Draft           RELOAD Client Extension            January 2012

   1.  Check if the PBA-F message contains the F flag set to 1.

   2.  MAG1 MUST establish a tunnel with MAG2(MAG of MN-S) for muticast
   data delivery.

   3.MAG1 MUST add route to Multicast Routing Information Base (MRIB)
   and send PIM Join/Prune messages through MAG1-MAG2 tunnel interface.

   4.MAG1 MUST create/update multicast state for MN,the iif of the
   multicast state MUST be set to MAG1-MAG2 tunnel interface.

   On receiving a PIM Join/Prune messages from MAG2-MAG1 tunnel
   interface,MAG2 MUST create/update multicast state for MN.

   1.Add MAG2-MAG1 tunnel interface to the oiflist of the multicast
   state on receiving a PIM Join message from MAG2-MAG1 tunnel
   interface.

   2.Delete MAG2-MAG1 tunnel interface from the oiflist of the multicast
   state on receiving a PIM Prune message from MAG2-MAG1 tunnel
   interface.

7.  Mobile Node Operation

   In this document,MN's MAG acquire MN-S's CoA from LMA according to
   MN-S's HoA,so A mobile node sends MLD Report messages including
   source and multicast addresses when it subscribes a multicast
   channel.

   The MN MUST operate as an "SSM-aware" host .  [RFC4604] provide the
   behavior of an "SSM-aware" host.

8.  Message Format Extension

8.1.  Proxy Binding Update with Source Address Finding Extension

Liu, et al.              Expires August 3, 2012                [Page 12]
Internet-Draft           RELOAD Client Extension            January 2012

      0               1               2               3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |            Sequence #         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|H|L|K|M|R|P|F|    Reserved   |             Lifetime          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Mobility Options                        .
     .                                                               .

     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure5 Proxy Binding Update with Source Address Finding Extension

   A Binding Update message that is sent by MAG to LMA is referred to as
   the "Proxy Binding Source Address Finding" message.  A new flag (F)
   is included in the Proxy Binding Update message with Source Address
   Finding extension (PBU-F).  The rest of the Binding Update message
   format remains the same as defined in[RFC3775] and with the
   additional (R), (M), and (P) flags, as specified in [RFC3963],
   [RFC4140], and [RFC5213], respectively.

   Source Address Finding Flag

   A new flag (F) is included in the Binding Update message to indicate
   to LMA that the Binding Update message is a Source Address Finding
   message.  In the normal PMIP operation, the flag must be set to 0.

   The PBU-F message is transfered for finding the MN-S's care-of
   address.  The rest of the PBU message remains unchanged.

8.2.  Proxy Binding Acknowledgement Message with Source Address Finding
      Extension

Liu, et al.              Expires August 3, 2012                [Page 13]
Internet-Draft           RELOAD Client Extension            January 2012

      0               1               2               3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |     Status    |K|R|P|F|Reserve|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Sequence #           |             Lifetime          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Mobility Options                        .
     .                                                               .

     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure6 Proxy Binding Update with Source Address Finding Extension

   A "Proxy Binding Acknowledgement" message is sent from LMA to MAG in
   response to a Proxy Binding Update message.  A new flag (F) is
   included in the Proxy Binding Acknowledgement message with Source
   Address Finding extension (PBA-F).  The rest of the Binding
   Acknowledgement message format remains the same as defined in
   [RFC3775] and with the additional (R) flag, as specified in [RFC3963]
   and [RFC5213], respectively.

   Source Address Finding Flag

   A new flag (F) is included in the Binding Acknowledgement message to
   indicate to MAG that the Binding Acknowledgement message is a Source
   Address Finding message.  In the normal PMIP operation, the flag must
   be set to 0.

   When (F) flag is specified in PBA-F message, the mobility options
   field includes "MN-S's care-of address"(Section 8.3).

8.3.  Care-of Address Option

Liu, et al.              Expires August 3, 2012                [Page 14]
Internet-Draft           RELOAD Client Extension            January 2012

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |   Type = TBD  |  Length = 16  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Care-of Address                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure7 Care-of Address Option

   The Care-of Address field contains the care-of address of MN-S.

   This option is valid only in PBA-F message.  On the reception of
   PBU-F, the LMA responds with a PBA-F message including the Care-of
   Address Option.

9.  Security Considerations

   TBD

10.  IANA Considerations

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

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

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

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,

Liu, et al.              Expires August 3, 2012                [Page 15]
Internet-Draft           RELOAD Client Extension            January 2012

              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", August 2006.

   [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")", August 2006.

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

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", April 2011.

   [draft-asaeda-multimob-pmip6-extension-07]
              Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for
              PIM-SM", October 2011.

   [draft-zuniga-multimob-pmipv6-ropt-01]
              Zuniga, J., Contreras, L., Bernardos, C., and S. Jeon,
              "Multicast Mobility Routing Optimizations for Proxy Mobile
              IPv6", October 2011.

Authors' Addresses

   Juan Liu
   ZTE Corporation
   RD Building 1,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Email: liu.juan45@zte.com.cn

Liu, et al.              Expires August 3, 2012                [Page 16]
Internet-Draft           RELOAD Client Extension            January 2012

   Wen Luo
   ZTE Corporation
   RD Building 1,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Wei Yan
   ZTE Corporation
   RD Building 1,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Email: yan.wei@zte.com.cn

Liu, et al.              Expires August 3, 2012                [Page 17]