Network Working Group                                     Hong-Ke Zhang
 Internet Draft                                            Xiao-Hua Chen
                                                          Jian-Feng Guan
                                                                 Bo Shen
                                             Beijing Jiaotong University
                                                              En-Hui Liu
                                                         Spencer Dawkins
                                            Huawei Technologies Co.,Ltd.
 Expires: July 2007                                    January 29, 2007
 
              Mobile IPv6 Multicast with Dynamic Multicast Agent
                  draft-zhang-mipshop-multicast-dma-03.txt
 
 
 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.
 
    This document may only be posted in an Internet-Draft.
 
    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 July 29, 2007.
 
 Abstract
 
    This document addresses the problem of delivering IPv6 multicast
    traffic to MN (Mobile Node). An approach named Mobile IPv6 Multicast
    with Dynamic Multicast Agent is proposed  which combines Movement
    Based Method [2] and Distance Based Method [3], Such a design allows
    MN to optimize multicast route, and meanwhile reduce the handoff
    frequency by selecting new multicast agent dynamically. In addition to
    weakening the triangle route problem and diminishing the influence of
    handoff to multicast, this approach provides global mobility in
    Internet without limitations on network topology. This draft is the
    same as the earlier version, it is just an update of it.
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 1]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
 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 [5].
 
 Table of Contents
 
 
    1. Introduction................................................2
    2. Concepts and Framework......................................3
    3. Operation of MSA............................................5
    4. Operation of DMA............................................7
    5. DMA switch decision-making algorithm in DMA.................9
    6. Security Considerations....................................10
    7. IANA Considerations........................................10
    8. Conclusions................................................10
    9. Acknowledgments............................................10
    10. References................................................11
       10.1. Normative References.................................11
       10.2. Informative References...............................11
    Author's Addresses............................................11
    Intellectual Property Statement...............................12
    Disclaimer of Validity........................................12
    Copyright Statement...........................................13
    Acknowledgment................................................13
 
 1. Introduction
 
    Multicast is an efficient way for forwarding data from one node or
    multi-nodes to multi-nodes. mobility support becomes an inevitable
    function of multicast technologies. The mobility support for IPv6
    protocol[1] has specified two basic methods for mobile multicast: 1)
    via a bi-directional tunnel from MN to its HA (Home Agent), which is
    called MIP-BT (Mobile IP Bi-directional Tunnel); 2) via a (local)
    multicast router on the foreign link being visited, which is called
    MIP-RS (Mobile IP Remote Subscription). In MIP-BT, MN tunnels its
    multicast group membership control packets to its HA, and the HA
    forwards multicast packets down the tunnel to the MN [1]. In MIP-RS,
    MN MUST use its care-of address and MUST NOT use the Home Address
    destination option when sending MLD (Multicast Listener Discovery)
    packets [1,4]. These two basic methods can retain multicast
    communications when MN moves, but some issues still exist.
 
    o  First, MIP-BT suffers from triangle route which is composed of MN-
       HA tunnel and HA-S multicast tree path. When the MN is far from
       its HA, the data forwarding path of multicast becomes
       deteriorative.
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 2]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    o  Second, multiple tunnels from a subnet to a HA are established in
       MIP-BT, when some MNs that come from the same home link attach at
       one AR (Access Router) in the subnet and these MNs join the same
       multicast group at the same time. This case is called tunnels
       congregation which will consume more network resources.
 
    o  Third, although the multicast path in MIP-RS is optimal, frequent
       handoffs of MN among subnets will produce much latency. Because
       when MN handovers , it will leave and re-join the multicast tree
       and multicast group frequently.
 
    This document addresses these above problems. An approach named
    Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed. This
    approach combines the advantages of MIP-BT and MIP-RS, selecting a
    new multicast agent based on both movement and distance dynamically,
    and the new selected agent is responsible for forwarding multicast
    data to the MN.
 
    Such a design optimizes the multicast routes and reduces handoff
    frequency. Beside releasing triangle route problem and diminishing
    the influence of handoff to multicast, it can also provide global
    mobility without limitation on network topology.
 
    In the following sections, we will first introduce the concepts and
    framework of this approach. Then, we will describe the details of
    Dynamic Multicast Agent switch procedure.
 
 
 2. Concepts and Framework
 
    In this document, two key roles are defined for Mobile IPv6 Multicast
    with Dynamic Multicast Agent.
 
         - MSA: Multicast Subnet Agent, which is the access router
           running multicast protocols in a subnet and forwarding the
           subscribed multicast data to the MN that visits the subnet.
 
         - DMA: Dynamic Multicast Agent, which is the current MSA or one
           of the previous MSAs of the MN acting as the leaf router in a
           multicast delivery tree the MN subscribed and forwarding the
           subscribed multicast data to the MN through its current MSA.
 
    The whole procedure of this approach is shown in Figure1.
 
 
 
 
 
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 3]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
         MN             pMSA             nMSA            DMA
         |                |                |              |
         |                |<----request----|              |
         |                |-----reply----->|              |
         |                |                |              |
         |---MLD query--->|                |              |
         |<--MLD report---|                |              |
         |                |                |              |
         |            Disconnect           |              |
         |                |                |              |
         |------ Unsolicited report------->|              |
         |                |       DMA handoff decision    |
         |                |                |              |
         |                |            connect            |
         |                |                |------------->|
         |                |                | Tunnel Setup |
         |                |                |<-------------|
         |<---------- MLD query------------|              |
         |                |                |              |
         |<=========deliver packets=======>|              |
         |                |                |              |
         |                |                |              |
              Figure 1 Operation process of MSA and DMA
 
    MSA is in charge of the local multicast group membership management
    and maintenance in a subnet via MLD protocol. MSA periodically sends
    regular MLD query messages to solicit regular MLD reports from the
    MNs visiting the subnet. To learn address information of neighbor
    MSAs, each MSA sends request message(e.g. PIM Hello message etc.)
    periodically, receivers send reply message to the sender, informing
    it their address information.
 
    In this approach, tunnel between nMSA and DMA is setup after MN has
    attached to nMSA. In order to shorten MN's handover latency, Fast
    Handover protocol[6] and CARD(Candidate Access Router Discovery)
    protocol[7] can be adopted. In these two approaches, tunnel is setup
    before the handover process, so after MN attaches to the nMSA, it can
    transmit data immediately, handover latency can be reduced
    Dramatically.
 
    When MN first subscribes a multicast group G, its current MSA becomes
    its initial DMA, which runs multicast protocol and joins the
    subscribed multicast delivery tree as a leaf router and then forwards
    the subscribed multicast data to the MN.
 
    Within an acceptable roaming distance, the DMA of a MN will not
    change although its visited MSA changes if its visited MSA doesn't
    yet have the group G membership in the subnet. When MN's current MSA
    is different from its DMA, its current MSA receives the group G
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 4]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    multicast data from its DMA via a short tunnel, and then forwards
    multicast data to the MN.
 
    Beyond this acceptable roaming distance, the MN's DMA will be
    switched to the new MSA that the MN currently is visiting. Then the
    MSA will run  multicast protocol and operate as DMA. In this case,
    multicast packets will be delivered from DMA directly to MN without
    tunnel.
 
    In this approach, not all visited MSA along MN's roaming path will
    join the subscribed multicast delivery tree by introducing the
    concept of DMA. only that selected as DMA need join the delivery
    trees as a leaf router.
 
    In comparison with other Agent selection approaches (e.g. MAP in
    HMIPv6 [5]), this DMA selection method is quite distributed, so the
    problem of performance bottleneck can be released.
 
    In comparison with MIP-BT approach, this DMA approach optimizes
    multicast transmission path by using shortest path from DMA to
    multicast source. So disadvantages of MIP-BT such as triangle route,
    large amount and long distance of tunnels can be avoided.
 
    In MIP-RS, every MSA is a leaf router of the subscribed multicast
    tree. once MN moves from the coverage of one MSA to another, it will
    leave the old MSA and attach to new MSA, which will consume more
    network resources. This DMA approach can reduce the frequency of
    remote multicast subscription and that of multicast delivery tree
    reconstructing dramatically, simplifying MN's signaling procedure,
    network performance is enhanced.
 
 3. Operation of MSA
 
    MSA is in charge of the local multicast group membership management
    and maintenance in a subnet via MLD protocol, including local hosts
    and visiting mobile nodes. MSA periodically sends regular MLD query
    messages to solicit regular MLD reports from the MN visiting the
    subnet.
 
    MSA maintains a Multicast Route Table used for receiving and
    forwarding the subscribed multicast data. There are six components
    kept in every entry of the Multicast Route Table: Group Address,
    Filter Modes(INCLUDE or EXCLUDE mode), Source_Address List,
    Tunnel_State, Tunnel_ID, and Egress Interface List.
 
    o  Filter Modes defines host and router parts of the protocol
       respectively to support the source filtering function.
 
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 5]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    o  Source_Address List records all source addresses which should be
       included or excluded according to the filter modes.
 
    o  Tunnel_ID is the identifier of a tunnel between MSA and DMA for
       MSA to receive the multicast data of the Group from DMA.
 
    o  Tunnel_State is a flag that represents whether Tunnel ID is valid
       and whether MSA has created a tunnel for the Group and is
       receiving the multicast data of the Group via the tunnel.
 
    o  Egress Interface List composes all receiversÂ’ egress interface of
       this group. multicast data should be forward to these interfaces.
 
    MSA also maintains a Visitor Table for support of DMA switch process.
    There are two elements kept in every entry of the Visitor Table: MN
    and DMA.
 
    o  MN item records the IP address of a MN visiting the subnet and
       being a multicast subscriber.
 
    o  DMA item records the IP address of the MN's DMA.
 
                     +------------------+
                     |  MN   |    DMA   |
                     |------------------|
                     |       |          |
                     +------------------+
    On arriving at a new visited subnet, a MN obtains a new CoA (Care of
    Address) and registers its current CoA with its Home Agent. Then the
    MN immediately sends unsolicited report message to its current
    subnet's MSA and the IP address of the previous subnet's MSA. The MSA
    communicates with the MN's previous MSA to obtain the IP address of
    the MN's previous DMA. When receiving the MLD group membership report
    sent from a visitor for group G, the MSA operates as follows:
 
    o  If there already is an entry for group G in the MSA's multicast
       route table, the MSA adds the MN to the entry's ingress interface
       list, and then examines the Tunnel_State. If the Tunnel_State is
       'YES', it represents that the MSA has already created a tunnel for
       the group and is receiving multicast data via the tunnel. In this
       case, it simply forwards the MLD group membership report message
       to the other end of the tunnel.
 
         - If there already is an entry for the MN in the MSA's Visitor
           Table, then the MSA keeps it.
 
         - Otherwise, if there is no entry for the MN in the MSA's
           Visitor Table, then the MSA creates a new entry for the MN. In
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 6]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
           order to optimize the delivery path, the DMA of the MN is
           switched to the MSA itself. And then the MSA informs the
           previous DMA to clear the states of the MN if available.
 
    o  If there is no entry for group G in the MSA's multicast route
       table, (i.e. the MN is the first group member of group G in the
       subnet), then MSA creates a new entry for group G in its multicast
       route table and adds the MN into the entry's outgoing interface
       list.
 
         - If there already is an entry for the MN in the MSA's Visitor
           Table, and if the MSA itself is the DMA of the MN, the MSA
           simply sends PIM Join messages to the multicast delivery tree.
           But if the MSA itself is not the DMA of the MN, the MSA
           creates a tunnel to the DMA of the MN, records the Tunnel_ID,
           sets the Tunnel_State to 'YES', and forwards the MLD group
           membership report message to the other end of the tunnel.
 
         - If there is no entry for the MN in the MSA's Visitor Table,
           the MSA creates an entry for the MN, and asks the MN's
           previous DMA if it needs to be switched to the MSA itself.
 
         - If the MN's DMA doesn't need to be switched to the MSA itself,
           the MSA adds the MN's DMA into the entry, creates a tunnel to
           the MN's DMA, records the Tunnel_ID, sets the Tunnel_State to
           'YES', and forwards the MLD group membership report message to
           the other end of the tunnel. If the MN's DMA needs to be
           switched to the MSA itself, the MSA adds itself into the entry,
           acts as the MN's DMA, and sends PIM Join messages to the
           multicast delivery tree.
 
    The MSA detects the MN's departure by the timeout of timer. When the
    MSA detects that a MN is departing from the current subnet, it
    deletes the entry for the MN in its Visitor Table. For each multicast
    group which the leaving MN subscribed, the MSA deletes the MN from
    the group's outgoing interface list.
 
 4. Operation of DMA
 
    DMA is in charge of joining the multicast delivery tree of the group
    G that a MN subscribed via PIM-based protocol as a leaf router. It
    receives the multicast data of group G and forwards the data to the
    MN through the MN's current MSA.
 
    When a MN first subscribes a multicast group G, its current MSA
    becomes its initial DMA. Within an acceptable roaming distance, the
    DMA of a MN will not change although its MSA changes if its MSA
    doesn't yet have the group G membership in the subnet. So the DMA of
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 7]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    a MN may be its current MSA or one of its previous MSAs. At a time
    only one DMA serves the MN for its subscribed multicast group G.
 
    When receiving the MLD group membership report sent from its served
    MN for a new group G, the DMA sends PIM Join messages to join the
    multicast delivery tree of the group G as a leaf router. When DMA
    switch happens or the MN leaves the group G, the DMA sends PIM Prune
    messages to prune itself from the multicast delivery tree of the
    group G.
 
    DMA maintains a table called History-Table to record the MN's recent
    attachment history, which is used for DMA to do DMA switch decision-
    making for the MN. There are three elements kept in every entry of
    the Table: MN, MSA and Increment.
 
    o  MN item records the IP address of the MN that the DMA serves;
 
    o  MSA item records the IP address of the MSA in each subnet that the
       MN recently roamed through;
 
    o  Increment item records the path increment of each MSA.
 
                     +------------------+
                     |  MN   |          |
                     +------------------+
                     |  MSA  | Increment|
                     |------------------|
                     | DMA   |    1     |
                     | MSA 1 |    2     |
                     | MSA 2 |    1     |
                     | ...   |   ...    |
                     | MSA n |    3     |
                     +------------------+
    The first MSA is the DMA itself, which creates the table, initiates
    the MN item, creates an entry for the first MSA and puts itself in
    the entry.
 
    When a MN enters into a new subnet, the MSA in this subnet receives
    the MLD group member report and the IP address of the MN's previous
    MSA from the MN. The MSA communicates with the MN's previous MSA to
    obtain the IP address of the MN's previous DMA. To maintain the
    recent attachment history table of the MN, the MN's DMA operates as
    follows:
 
    According to the operation of MSA as described in Section 3,
 
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 8]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    o  If the DMA of the MN is switched to the MSA itself, the MSA
       informs the previous DMA to clear the states of the MN if
       available. Then the MSA acts as the MN's current DMA, creates and
       initiates the recent attachment history table for the MN. The MN's
       previous DMA deletes the recent attachment history table of the MN
       and prunes itself from the multicast delivery tree of the group G.
 
    o  If the DMA of the MN is not switched to the MSA itself, the MSA
       communicates with the MN's previous DMA to ask whether it can
       continue acting as the MN's DMA. The MN's previous DMA creates an
       entry for the MSA in the recent attachment history table of the MN,
       and then makes the decision according to the DMA switch decision-
       making algorithms in DMA as described in Section 5.
 
         - If the decision is 'Yes', then the MSA acts as the MN's
           current DMA, creates and initiates the recent attachment
           history table for the MN. The MN's previous DMA deletes recent
           attachment history table of the MN and prunes itself from the
           multicast delivery tree of the group G.
 
         - If the decision is 'No', the MN's previous DMA continues
           acting as the MN's DMA. The MSA receives the group G multicast
           data from the DMA via a tunnel and forwards the data to the MN.
 
 5. DMA switch decision-making algorithm in DMA
 
    In DMA, the key point is the algorithm of DMA switch decision-making
    based on movement and distance. As described in Section 4, DMA
    maintains a table to record the MN's recent attachment history
    (namely History_Table), which is used for DMA to do DMA switch
    decision-making for the MN.
 
    The DMA switch decision-making algorithm could be simple or precise.
    The main principle is that there should not be any DMA switch for an
    MN within an acceptable roaming distance if the MN's visited MSA
    doesn't yet have the group G membership in the subnet.
 
    Here, we just provide a simple algorithm via checking the path
    increment of the recently joined MSA.
 
    When the path increment of MSAs in the DMA's History_Table reaches
    the assigned threshold, DMA switch happens. So the DMA deletes the
    recent attachment history table of the MN and prunes itself from the
    multicast delivery tree of the group G. Meanwhile, the MN's current
    MSA acts as its new DMA, which joins the multicast delivery tree of
    the group G as a leaf router, creates and initiates the recent
    attachment history table for the MN.
 
    The path increment of a MSA can be defined as:
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                 [Page 9]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    1 + Minimum [Distance(MSA,DMA),Distance(DMA,MN)], where Distance[x]
    is the minimum integer greater than or equal to x. For example, the
    path increment of a MSA is 1 if the MSA itself is the MN's DMA.
 
 6. Security Considerations
 
    This specification introduces a new concept to Mobile IPv6, namely, a
    Dynamic Multicast Agent that acts as a multicast agent. It is crucial that
    the security relationship between the Multicast Source Agent and the DMA
    is strong; it MUST involve mutual authentication, integrity
    protection, and protection against replay attacks. Confidentiality
    may be needed for payload traffic. The absence of any of these
    protections may lead to malicious mobile nodes impersonating other
    legitimate ones or impersonating a DMA. Any of these attacks will
    undoubtedly cause undesirable impacts to the mobile node's
    communication with all correspondent nodes.
 
 7. IANA Considerations
 
    See [9] for instructions on IANA allocation.
 
 8. Conclusions
 
    This document has discussed the delivering of IPv6 multicast traffic
    to mobile nodes. The presented approach is a compromised approach
    between MIP-BT and MIP-RS, using a Dynamic Multicast Agent to join
    the multicast delivery trees instead of a static multicast agent. The
    use of MSA and DMA is the key feature of the approach. The purpose is
    to optimize the multicast path to MNs, and meanwhile reduce the
    latency and the impact on multicast trees which result from the
    roaming of MNs. By introducing the concept of DMA, it reduces the
    frequent remote subscription and multicast delivery tree
    restructuring, and avoids the long tunnels and the large number of
    tunnels.
 
 9. Acknowledgments
 
    We would like to thank Thomas Schmidt, and Kishore Mundra for their
    valuable comments and suggestions on this document.
 
 
 
 
 
 
 
 
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                [Page 10]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
 10. References
 
 10.1. Normative References
 
    [1]  Johnson, D., Perkins C., and Arkko, J., "Mobility Support in
         IPv6", RFC 3775, June 2004.
 
    [2]  Zhang, J. Y. "Location Management in Cellular Networks". 2001.
 
    [3]  Bar-Noy, A. Kessler, I. and Sidi, M. "Mobile Users: To update
         or not to Update?", Wireless Networks Journal, 1995,1(2):175-86.
 
    [4]  Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.
 
    [5]  Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L.
         "Hierarchical Mobile IPv6 mobility management", draft-ietf-
         mipshop-hmipv6-04 (work in progress), December 2004.
 
    [6]  Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC4068,
         July 2005.
 
    [7]  M. Liebsch, Ed., A. Singh, Ed.,H. Chaskar.,D. Funato.,E. Shim
         "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
 
 10.2. Informative References
 
    [8]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.
 
    [9]  Kempf, J., "Instructions for Seamoby and Experimental Mobility
         Protocol IANA Allocations", RFC 4065, July 2005.
 
 Author's Addresses
 
    Hong-Ke Zhang, Bo Shen, Bing-Yi Zhang
    IP lab, Beijing JiaoTong Univ.
    Beijing, China, 100044
 
    Phone: +86 10 51685677
    Email: hkzhang@center.njtu.edu.cn
           bingyizhang@hotmail.com
 
 
 
 
 
 
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                [Page 11]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
    En-Hui LIU
    Huawei Technologies Co., Ltd.
    Beijing, China, 100085
 
    Phone: +86-10-82882495
    Fax:+86-10-82882537
    Email: LEH10814@huawei.com
 
    Spencer Dawkins
    Huawei Technologies Co., Ltd.
    TX, USA, 75075
    Email: sdawkins@futurewei.com
 
 
 Intellectual Property Statement
 
    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.
 
 Disclaimer of Validity
 
    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 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.
 
 
 
 
 Hong-Ke Zhang et al.    Expires July 29, 2007                [Page 12]


 Internet-Draft     Mobile IPv6 Multicast with DMA         January 2007
 
 
 Copyright Statement
 
    Copyright (C) The Internet Society (2007).
 
    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.
 
 Acknowledgment
 
    Funding for the RFC Editor function is currently provided by the
    Internet Society.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Hong-Ke Zhang et al.    Expires July 29, 2007                [Page 13]