MULTIMOB Group                                                JC.Zuniga
Internet Draft                                                     G.Lu
Intended status: Standards Track                               A.Rahman
Expires: April 15, 2010                InterDigital Communications, LLC
                                                       October 15, 2009


            Support Multicast Services Using Proxy Mobile IPv6
                   draft-zuniga-multimob-smspmip-00.txt


Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/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 16 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.







Zuniga, et al.          Expires April 15, 2010                 [Page 1]

Internet-Draft     Multicast Services using PMIPv6         October 2009


Abstract

   This document describes how multicast services can be supported with
   Proxy Mobile IPv6 protocol [RFC5213], Multicast Listener Discovery
   (MLDv2) protocol [RFC3810], and Internet Group Management Protocol
   (IGMPv3)[RFC3376]. This document analyzes scenarios for multicast
   service establishment and mobility. It also proposes the use of a
   dedicated LMA for multicast services.

Table of Contents


   1. Introduction...................................................2
   2. Conventions and Terminology....................................3
   3. Single LMA Supporting both Unicast and Multicast Services......3
      3.1. Architecture..............................................3
      3.2. Multicast Establishment...................................4
      3.3. Multicast Mobility........................................5
   4. Dedicated LMA Supporting Multicast Services....................6
      4.1. Architecture..............................................6
      4.2. Multicast Establishment...................................7
      4.3. Multicast Mobility........................................9
   5. Enhanced Multicast Mobility Support...........................10
      5.1. Architecture.............................................11
      5.2. Multicast Mobility.......................................11
   6. MLD/IGMP Enhancements.........................................14
      6.1. "Join" before Handover...................................14
      6.2. Fast "Join" after HO.....................................14
   7. Security Considerations.......................................14
   8. IANA Considerations...........................................15
   9. References....................................................15
      9.1. Normative References.....................................15
      9.2. Informative References...................................15
   10. Acknowledgments..............................................16

1. Introduction

   Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving IP
   mobility challenge. In a Proxy Mobile IPv6 domain, Mobile Access
   Gateway (MAG) behaves as a proxy mobility agent in the network and
   does the mobility management on behalf of the mobile node attached to
   the network. Local Mobility Anchor (LMA) is the home agent for the
   mobile node and the topological anchor point. Proxy Mobile IPv6 is
   designed mainly for unicast services.

   The Internet Group Management Protocol (IGMP) [RFC3376] is the
   protocol used by IPv4 systems to report their IP multicast group


Zuniga, et al.          Expires April 15, 2010                 [Page 2]

Internet-Draft     Multicast Services using PMIPv6         October 2009


   memberships to neighboring multicast routers. The Multicast Listener
   Discovery Protocol (MLD)[RFC3810] is used in a similar way as IGMP by
   IPv6 routers to discover the presence of multicast listeners.
   However, IGMP/MLD are not designed to address mobility issues.

   Supporting multicast services has been under discussions within the
   working group. This document focuses on addressing multicast mobility
   scenarios using the Proxy Mobile IPv6 and IGMP/MLD protocols, and
   proposing a new deployment architecture with a dedicated LMA for
   multicast services. This document also provides two mechanisms to
   reduce latency for IGMP/MLD.

2. Conventions and 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].

   This document uses the terminology defined in [RFC5213], [RFC3775],
   [RFC3810].

3. Single LMA Supporting both Unicast and Multicast Services

   This section describes how multicast services and mobility can be
   supported based on how Proxy Mobile IPv6 and MLD protocols work now.

   To improve service continuity, some enhancements can be made, without
   modifying the protocols. The enhancements are discussed in section 4,
   5, and 6.

3.1. Architecture

   Figure 1 illustrates the architecture using Proxy Mobile IPv6. In
   this architecture, MAG provides multicast proxy functions as defined
   in [RFC4605]. LMA serves as the multicast router and forwards
   multicast services. LMA is also the anchor point for unicast
   services.












Zuniga, et al.          Expires April 15, 2010                 [Page 3]

Internet-Draft     Multicast Services using PMIPv6         October 2009



         ***  ***  ***  ***      ***  ***  ***  ***
        *   **   **   **   *    *   **   **   **    *
       *                    *  *                     *
        * Unicast Services *    * Multicast Services*
       *                    *  *                     *
        *   **   **   **   *    *   **   **   **    *
         ***  ***  ***  ***      ***  ***  ***  ***
                     |              |
                      |            |
                       |          |
                        |        |
                         |      |
                          +-----+
                          | LMA |
                          +-----+
                        //        \\
                       //          \\
                      //            \\
                     //              \\
                +-----+              +-----+
                |p-MAG|              |n-MAG|
                +-----+              +-----+
                   |                    |
                   |                    |
                  {MN} -- Handover ->  {MN}

                 Figure 1 Multicast Mobility Architecture

3.2. Multicast Establishment

   Figure 2 shows the procedures of MN attachment and initiation of
   unicast and multicast services. The unicast service is shown for the
   purpose of completion and comparison.

   The procedures from "MN Attachment" to the establishment of unicast
   service are the same as defined in Proxy Mobile IPv6 [RFC5213]. MAG
   provides multicast proxy functions as defined in [RFC4605]. LMA
   serves as the multicast router and forwards multicast services. The
   MLD Query message may occur before the MLD Report is sent, and they
   are not shown in the figure for simplicity.








Zuniga, et al.          Expires April 15, 2010                 [Page 4]

Internet-Draft     Multicast Services using PMIPv6         October 2009


      MN               MAG                 LMA
      |                 |                   |
   MN Attached          |                   |
      |                 |                   |
      |                 |                   |
      |---- Rtr Sol --->|                   |
      |                 |                   |
      |                 |--------PBU------ >|
      |                 |                   |
      |                 |<-------PBA------- |
      |                 |                   |
      |                 |                   |
      |                 |===Bi-Dir Tunnel== |
      |                 |                   |
      |<----Rtr Adv---- |                   |
      |                 |                   |
     IP address         |                   |
   Configuration        |                   |
      |                 |                   |
      |< -------Unicast Traffic----------- >|
      |                 |                   |
      |                 |                   |
      |---MLD Report-- >|                   |
      |                 |-----MLD Report-- >|
      |                 |                   |
      |<--------Multicast Traffic--------- >|
      |                 |                   |
        Figure 2 MN Attachment and Multicast Service Establishment

3.3. Multicast Mobility

   Figure 3 shows the procedures of re-establishing the multicast
   services when the MN moves within the same LMA. The MN shown in the
   figure has both unicast and multicast sessions. This figure shows a
   basic scenario that the MN needs to re-join the multicast services
   after handover. There are ways to improve the multicast mobility
   support and they are discussed in section 4, 5 and 6.












Zuniga, et al.          Expires April 15, 2010                 [Page 5]

Internet-Draft     Multicast Services using PMIPv6         October 2009


      MN              p-MAG             n-MAG           LMA
      |                 |                 |              |
      |                 |                 |              |
      |< --------------- Unicast Traffic -------------- >|
      |                 |                 |              |
      |< ------------- Multicast Traffic -------------- >|
      |                 |                 |              |
Detached from p-MAG     |                 |              |
      |                 |                 |              |
      |                 |----------- DeReg PBU--------- >|
      |                 |                 |              |
      |                 |< -------------PBA ------------ |
Attached to n-MAG       |                 |              |
      |                 |                 |              |
      |------------Rtr Sol ------------- >|              |
      |                 |                 |-----PBU---- >|
      |                 |                 |              |
      |                 |                 |< ---PBA----- |
      |                 |                 |              |
      |                 |                 |===Bi Dir === |
      |                 |                 |   tunnel     |
      |< ----------Rtr Adv--------------- |              |
      |                 |                 |              |
      |< --------------Unicast Traffic ---------------- >|
      |                 |                 |              |
      |                 |                 |              |
      |---------------MLD Report-------- >|              |
      |                 |                 |-MLD Report- >|
      |                 |                 |              |
      |<---------------Multicast Traffic--------------- >|
      |                 |                 |              |
                        Figure 3 Multicast Mobility



4. Dedicated LMA Supporting Multicast Services

   A PMIPv6 domain may receive data from sources of both the unicast
   services and multicast services.  A dedicated LMA can be used to
   serve as the anchor for multicast services. This section describes
   how the multicast LMA works in scenarios of mobile node attachment
   and multicast mobility.

4.1. Architecture

   Figure 4 shows a PMIPv6 domain. One LMA is dedicated to unicast
   services, and one is dedicated to multicast services. A MAG may


Zuniga, et al.          Expires April 15, 2010                 [Page 6]

Internet-Draft     Multicast Services using PMIPv6         October 2009


   connect to both LMAs, or only one LMA. A MN may receive unicast
   and/or multicast services. In Figure 4, MN1 and MN2 have either
   unicast or multicast services, or both. MN3 has multicast services
   only.



         ***  ***  ***  ***      ***  ***  ***  ***
        *   **   **   **   *    *   **   **   **    *
       *                    *  *                     *
        * Unicast Services *    * Multicast Services*
       *                    *  *                     *
        *   **   **   **   *    *   **   **   **    *
         ***  ***  ***  ***      ***  ***  ***  ***
                 |                       |
                 |                       |
                 |                       |
              +-----+                 +-----+
              | LMA |                 | LMA |
              +-----+                 +-----+
                  \\                    // ||
                   \\                  //  ||
                    \\                //   ||
                     \\              //    ||
                      \\            //     ||
                       \\          //      ||
                        \\        //       ||
                         \\      //        ||
                          \\    //         ||
                          +-----+       +-----+
                          | MAG |       | MAG |
                          +-----+       +-----+
                          |     |          |
                          |     |          |
                        {MN1} {MN2}      {MN3}
        Figure 4 Architecture of Dedicated LMA as Multicast Anchor

4.2. Multicast Establishment

   Figure 5 shows the procedure when two mobile nodes attach to the MAG,
   and establish Proxy Mobile IPv6 tunnels, with the unicast LMA and
   multicast LMA respectively.







Zuniga, et al.          Expires April 15, 2010                 [Page 7]

Internet-Draft     Multicast Services using PMIPv6         October 2009



      MN1        MN2        MAG        LMA        LMA
       |          |          |      (Unicast) (Multicast)
       |          |          |          |          |
  MN1 Attachment  |          |          |          |
       |          |          |          |          |
       |------Rtr Sol----- ->|          |          |
       |          |          |--PBU -- >|          |
       |          |          |          |          |
       |          |          |<-- PBA --|          |
       |          |          |          |          |
       |          |          |=Unicast= |          |
       |          |          |  Tunnel  |          |
       |<-----Rtr Adv ------ |          |          |
       |          |          |          |          |
       |< ------ Unicast Traffic------ >|          |
       |          |          |          |          |
       |    MN2 Attachment   |          |          |
       |          |          |          |          |
       |          |-Rtr Sol >|          |          |
       |          |          |          |          |
       |          |-- MLD -->|          |          |
       |          |  Report  |          |          |
       |          |          |----- MLD Report---> |
       |          |          |          |          |
       |          |          |------------PBU---- >|
       |          |          |          |          |
       |          |          |< ----------PBA----- |
       |          |          |          |          |
       |          |          |==Multicast Tunnel ==|
       |          |          |          |          |
       |          |<Rtr Adv- |          |          |
       |          |          |          |          |
       |          |< ----- Multicast Traffic ---- >|
       |          |          |          |          |

        Figure 5 MN Attachment and Multicast Service Establishment

   In the illustrated scenario, both MN1 and MN2 are attached to the
   same MAG. MN1 is a "traditional" user for unicast services. The MAG
   establishes the Proxy Mobile IPv6 tunnel with LMA for unicast
   services as defined in [RFC5213].

   MN2 requires multicast services. It may indicate its multicast
   request in the Router Solicitation request. MAG sends the Proxy
   Binding Update to the multicast LMA, and establishes the tunnel for
   multicast services. MAG may use a multicast CoA so the multicast


Zuniga, et al.          Expires April 15, 2010                 [Page 8]

Internet-Draft     Multicast Services using PMIPv6         October 2009


   tunnel can be shared by multiple MNs that subscribed to the same
   multicast services. The MN sends the MLD report message as defined in
   [RFC3810].

   A MN may have multiple interfaces, and requires both unicast and
   multicast services simultaneously.

   The multicast tunnel may be downlink-only or bi-directional.

4.3. Multicast Mobility

   Figure 6 illustrates the mobility scenario for multicast services,
   using the dedicated multicast LMA. The figure shows a MN with both
   unicast services and multicast services. In the scenario discussed
   below, it is assumed that the p-MAG and n-MAG are connected to both
   the unicast LMA and multicast LMA.

   When the MN detaches from the p-MAG, the p-MAG deregisters from the
   unicast LMA, as defined in [RFC5213]. However, the p-MAG should keep
   the multicast tunnel with the multicast LMA if there are still other
   MNs using the multicast tunnel. Even if there is no MN on the
   multicast tunnel, the p-MAG may decide to keep the multicast tunnel.

   When the MN attaches to the n-MAG, the MN sends MLD reports, and the
   n-MAG establishes the multicast tunnel with the multicast LMA, same
   as described in section 4.2.

   It is possible that the multicast tunnel is already available at n-
   MAG when the MN attaches to n-MAG.  Therefore the n-MAG can
   distribute the multicast traffic to the MN, using either the unicast
   or multicast L2 connection between n-MAG and MN.


















Zuniga, et al.          Expires April 15, 2010                 [Page 9]

Internet-Draft     Multicast Services using PMIPv6         October 2009


       MN         p-MAG        n-MAG        LMA        LMA
       |            |           |         (Unicast)(Multicast)
       |            |           |            |          |
       |            |           |            |          |
       |            |=====Unicast Tunnel==== |          |
       |            |           |            |          |
       |            |========= Multicast Tunnel ======= |
       |            |           |            |          |
     MN Detached    |           |            |          |
       |            |           |            |          |
       |     remove unicast     |            |          |
       |          tunnel        |            |          |
       |            |-------DeReg PBU ----- >|          |
       |            |           |            |          |
       |            |< ---------PBA--------- |          |
       |            |           |            |          |
     MN Attached    |           |            |          |
      To n-MAG      |           |            |          |
       |            |           |            |          |
       |---------Rtr Sol------ >|            |          |
       |            |           |            |          |
       |----------MLD Report-- >|            |          |
       |            |           |---- MLD Report ----- >|
       |            |           |            |          |
       |            |           |------- PBU --------- >|
       |            |           |            |          |
       |            |           |<------PBA ----------- |
       |            |           |            |          |
       |< --------Rtr Adv------ |==Multicast Tunnel==== |
       |            |           |            |          |
       |            . . .                               |
       |      Establishment of new unicast tunnel is    |
       |          the same as defined in [RFC5213]      |
       |            . . .                               |
       |            |           |            |          |

                        Figure 6 Multicast Mobility

5. Enhanced Multicast Mobility Support

   This section discusses how multicast mobility can be enhanced when
   indications of handover triggers are available. Traditionally, the
   new PMIP tunnel is established after the MN is attached to the n-MAG,
   which can cause long delay for multicast services. In this section,
   handover triggers are used to establish the tunnels before the MN is
   attached to the n-MAG.



Zuniga, et al.          Expires April 15, 2010                [Page 10]

Internet-Draft     Multicast Services using PMIPv6         October 2009


5.1. Architecture

   The handover scenarios can apply to the single LMA architecture
   illustrated in section 3.1, or the dedicated multicast LMA
   illustrated in section 4.1. They can apply to both unicast and
   multicast services. For simplicity, only the single LMA architecture
   and multicast services are depicted in the figures.

5.2. Multicast Mobility

   Handover triggers may occur in the MN or the network. The MN can get
   predictive indications of imminent handover, for example, using some
   L2 measurements. A MN can initiate a handover due to the request of
   an application. A MN can also get handover command from the network.
   In such cases, the MN can send an indication of imminent handover to
   the p-MAG. The p-MAG forwards the indication to n-MAG, including the
   multicast information of the MN. This helps the n-MAG to establish
   the multicast with LMA faster. The n-MAG can use a multicast CoA for
   the multicast tunnel. Therefore when the MN attaches to the n-MAG,
   the multicast service can be available. The figure shows the binding
   update occurs before the handover. Binding update may happen after
   the handover. The p-MAG can decide to keep or tear down the old
   tunnel. The procedure is illustrated in Figure 7.

   The protocol to transport the HO trigger message is beyond the scope
   of this document. For example, the context transfer method proposed
   in [RFC4067] can be used.






















Zuniga, et al.          Expires April 15, 2010                [Page 11]

Internet-Draft     Multicast Services using PMIPv6         October 2009


      MN              p-MAG             n-MAG           LMA
      |                 |                 |              |
   HO trigger           |                 |              |
    at MN               |                 |              |
      |                 |                 |              |
      |---HO Trigger -->|                 |              |
      |                 |                 |              |
      |                 |                 |              |
      |                 |---HO Trigger-- >|              |
      |                 | (MN multicast)  |              |
      |                 |      info       |              |
      |                 |                 |              |
      |                 |                 |              |
      |                 |                 |-----PBU---- >|
      |                 |                 |              |
      |                 |                 |< ---PBA----- |
      |                 |                 |              |
      |                 |                 |===Multicast= |
      |                 |                 |     tunnel   |
      |                 |                 |              |
MN Detaches from p-MAG  |                 |              |
MN Attaches to n-MAG    |                 |              |
      |                 |                 |              |
      |                 |                 |              |
      |<----------------- Multicast Traffic ----------- >|
      |                 |                 |              |

           Figure 7 Indication of Handover Triggers between MAGs





















Zuniga, et al.          Expires April 15, 2010                [Page 12]

Internet-Draft     Multicast Services using PMIPv6         October 2009


   Figure 8 illustrates an alternative way that the HO trigger is passed
   from the MN to p-MAG, and p-MAG forwards it to LMA. This scenario
   applies when there is no direct interface between p-MAG and n-MAG.

   To reuse the mechanisms defined in [RFC5213] without modification,
   the HO trigger is forwarded from LMA to n-MAG, while n-MAG initiates
   the tunnel establishment procedure with LMA as defined in [RFC5213].



     MN              p-MAG             n-MAG            LMA
      |                 |                 |               |
 HO Trigger             |                 |               |
    at MN               |                 |               |
      |                 |                 |               |
      |--HO trigger --->|                 |               |
      |                 |                 |               |
      |                 |----------- HO Trigger -------- >|
      |                 |        (MN multicast info)      |
      |                 |                 |               |
      |                 |                 |<-HO Trigger --|
      |                 |                 |(MN multicast) |
      |                 |                 |     info      |
      |                 |                 |               |
      |                 |                 |------PBU---- >|
      |                 |                 |               |
      |                 |                 |< --- PBA----- |
      |                 |                 |               |
      |                 |                 |===Multicast== |
      |                 |                 |     tunnel    |
      |                 |                 |               |
MN Detaches from p-MAG  |                 |               |
MN Attaches to n-MAG    |                 |               |
      |                 |                 |               |
      |                 |                 |               |
      |<-----------------Multicast Traffic-------------- >|
      |                 |                 |               |

              Figure 8 Indication of Handover Triggers to LMA

   The handover trigger may come from the network side, for example, due
   to operator policies, load balancing, etc.

   If either LMA or MAG is aware of the imminent handover from the
   network side, LMA or MAG can initiate the establishment of the
   multicast tunnels. The steps between MAG and LMA are the same as
   illustrated in Figure 7 and Figure 8.


Zuniga, et al.          Expires April 15, 2010                [Page 13]

Internet-Draft     Multicast Services using PMIPv6         October 2009


   There are cases that the HO trigger is not generated at p-MAG or LMA.
   For example, the HO trigger may be originated from a policy control
   entity in the network, and passed to a corresponding mobility entity
   in the MN. The MN can send the HO trigger to the p-MAG, same as the
   procedures shown in Figure 7 and Figure 8.

6. MLD/IGMP Enhancements

   The multicast services can be interrupted after MN handover, due to
   service re-initiation. Therefore the key to enhance the MLD/IGMP
   performance is to reduce the delay caused by service re-initiation.

   Two methods to reduce handover delay for multicast services are
   proposed below.

6.1. "Join" before Handover

   In the scenarios discussed in section 5, a HO trigger is sent to n-
   MAG before the MN attaches to n-MAG. n-MAG can use the multicast
   information in the HO trigger message to enable the multicast
   services before the handover occurs. This is like the MN "joins"
   before the handover.

   In an alternative architecture, if imminent handover is known by a
   mobility management entity in the network, the mobility management
   entity can "join" the multicast group on behalf of the MN with the
   appropriate multicast router in the target network.

6.2. Fast "Join" after HO

   Right after the handover is completed, the mobility management entity
   in the MN can trigger the sending of a MLD/IGMP Report immediately,
   without waiting for the Query from the multicast router.

   The above proposed mechanisms can be used independently or jointly.
   For example, if a "join" before handover is not working, a fast
   "join" after HO can still work and reduce the service delay.

7. Security Considerations

   This draft discusses the operations of existing protocols without
   modifications. It does not introduce new security threats beyond the
   current security considerations of PMIPv6 [RFC5213], MLD [RFC3810],
   IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605].





Zuniga, et al.          Expires April 15, 2010                [Page 14]

Internet-Draft     Multicast Services using PMIPv6         October 2009


8. IANA Considerations

   This document makes no request of IANA.

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.

   [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
             Syntax Specifications: ABNF", RFC 2234, Internet Mail
             Consortium and Demon Internet Ltd., November 1997.

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

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

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

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

9.2. Informative References

   [I-D.deng-multimob-pmip6-requirement]
             Deng, H., Schmidt, T., Seite, P., and P.Yang, "Multicast
             Support Requirements for Proxy Mobile IPv6", draft-deng-
             multimob-pmip6-requirements-02 (Work in progress), July 13,
             2009.

   [I-D.schmidt-multimob-pmipv6-mcast-deployment-01] Schmidt, T.,
             Waehlisch, M., Sarikaya, B., and S.Krishnan, "A Minimal
             Deployment Option for Multicast Listeners in PMIPv6
             Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-01
             (Work in progress), June 29, 2009.



Zuniga, et al.          Expires April 15, 2010                [Page 15]

Internet-Draft     Multicast Services using PMIPv6         October 2009


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

10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Juan Carlos Zuniga
   InterDigital Communications, LLC
   Email: JuanCarlos.Zuniga@InterDigital.com


   Guang Lu
   InterDigital Communications, LLC
   Email: Guang.Lu@InterDigital.com


   Akbar Rahman
   InterDigital Communications, LLC
   Email: Akbar.Rahman@InterDigital.com



























Zuniga, et al.          Expires April 15, 2010                [Page 16]