Subject: [multimob] (no subject)

From: "Tony" <[email-masked]>
Date: Wed, 4 Jul 2007 09:26:14 +0800

Hello every

	Recently, I writed and submitted a new draft of MIPv6 extensions for mobile multicast.
	Welcom everyone to comment.
	
	Details:
	                                                                                              
        Title           : MIPv6 Extensions for Mobile Multicast: Problem Statement
        Author(s)       : Hongke Zhang, et al.
        Filename        : draft-zhang-multimob-memcast-ps-00.txt
        Pages           : 17
        Date            : 2007-07-01
 		Abstract 

    Mobile multicast is a research hotspot and gets more and more study 
    recently. But the current mobility management specifications can not 
    provide effective multicast packets transmission, and existing mobile 
    multicast schemes are not generally accepted. In this memo, we 
    discuss the problems arising from mobile multicast and address the 
    solutions of MIPv6 extensions to support mobile multicast services.  
 
===============================================================================

 Multimob                                                 Hong-ke Zhang 
 Internet Draft                                          Jian-feng Guan 
 Expires: January 2008                                       De-yun Gao 
                                                          Hua-chun Zhou 
                                                            Ya-juan Qin 
                                            Beijing JiaoTong University 
                                                           July 2, 2007

           MIPv6 Extensions for Mobile Multicast: Problem Statement 
                   draft-zhang-multimob-memcast-ps-00.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 January 2, . 

 Abstract 

    Mobile multicast is a research hotspot and gets more and more study 
    recently. But the current mobility management specifications can not 
    provide effective multicast packets transmission, and existing mobile 
    multicast schemes are not generally accepted. In this memo, we 
    discuss the problems arising from mobile multicast and address the 
    solutions of MIPv6 extensions to support mobile multicast services.  

 Zhang et al            Expires January 2, 2008                [Page 1] 
  
 Internet-Draft               MEMCAST-PS                      July 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 [1]. 

 Table of Contents 

    1. Introduction.................................................2 
    2. Terminology..................................................3 
    3. Problem Description..........................................3 
       3.1. General issues..........................................4 
          3.1.1. Reconstruction of multicast delivery tree..........5 
          3.1.2. Mobile source issues...............................5 
          3.1.3. Mobile receiver issues.............................5 
          3.1.4. Mobile forwarder issues............................5 
       3.2. Mobility support specification issues...................5 
       3.3. Multicast control protocol issues.......................7 
       3.4. Multi-hop mobile multicast issues.......................7 
       3.5. Multihoming mobile multicast issues.....................8 
    4. Solutions....................................................8 
       4.1. MIPv6 extensions........................................9 
          4.1.1. MIPv6 signaling extensions.........................9 
          4.1.2. Multicast route optimization.......................9 
       4.2. MLD extensions..........................................9 
       4.3. Multi-hop mobile multicast.............................10 
       4.4. Multihoming mobile multicast...........................11 
    5. Security Considerations.....................................11 
    6. IANA Considerations.........................................11 
    7. Conclusions.................................................11 
    8. Acknowledgments.............................................12 
    9. References..................................................13 
       9.1. Normative References...................................13 
       9.2. Informative References.................................13 
    Author's Addresses.............................................16 
    Intellectual Property Statement................................16 
    Disclaimer of Validity.........................................16 
    Copyright Statement............................................17 
    Acknowledgment.................................................17 
     
 1. Introduction 

    With the development of various mobile technologies, mobile multicast 
    becomes more important because it can provide many applications such 
    as mobile conference, on-line game. Mobile multicast has to solve 
    mobility problem of multicast subscriber (multicast source and 

 Zhang, Guan et al.     Expires January 2, 2008                [Page 2] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    multicast receiver) and it includes link layer handover such as WLAN, 
    WiMAX, UMTS and network layer handover such as MIPv6 [2] and its 
    variants such as FMIPv6 [9], HMIPv6 [10]and NEMO [3] which can 
    provide the mobility support for mobile node or mobile network. 
    However, these specifications do not provide an effective method to 
    support mobile multicast services.  

    MIPv6 is designed to support unicast communication by caching the 
    binding between HoA and CoA of MN, and route the packets addressed to 
    HoA to CoA transparently. As for the multicast data, two basic 
    methods, Bi-directional Tunnel (BT) and Remote Subscribe (RS) methods 
    were proposed. BT is transparent and has lower join latency, but 
    introduces triangular routing and additional transmission overheads. 
    While RS has effective routing, but increases long join delay 
    especially when foreign networks do not have the multicast states of 
    MN interested, and even result in multicast service disruption if 
    foreign networks do not support multicast. Based on BT and RS, 
    several improved schemes were proposed in past few years [11], and 
    try to make the tradeoff between BT and RS, using different multicast 
    agent selection algorithms or modifying the mobility support 
    specifications [12].  

    The prime problem of mobile multicast is that the current mobility 
    support specifications such as MIPv6 can not provide effective 
    multicast transmission mechanism. The binding cache in MIPv6 only 
    records the mapping between HoA and CoA which can be used to reroute 
    the unicast packets directly. However, for multicast data, no such 
    mechanism is defined. So, in this memo, we specify the problems scope 
    for MIPv6 extensions of mobile multicast and describe the potential 
    solutions.  

 2. Terminology 

    The terminology used in this memo is already defined in MIPv6, FMIPv6, 
    HMIPv6 and NEMOv6. 

 3. Problem Description 

    Mobile multicast derives from the development of Mobile IP and 
    multicast and the current mobile multicast schemes are mainly based 
    on the combination of multicast and Mobile IP. So, the mobile 
    multicast problem comes from two parts, first part is multicast and 
    the second part is mobility support specifications.  

    Multicast provides an effective group communication mechanism in IP 
    layer to reduce the redundant packets, and it is based on host group 
    model [6] which consists of multicast route protocol such as PIM-SM 

 Zhang, Guan et al.     Expires January 2, 2008                [Page 3] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    [7] and multicast group control protocol such as MLDv1 [4] and MLDv2 
    [5]. Multicast routing protocol constructs the multicast delivery 
    tree and maintains the multicast group states in multicast router, 
    while multicast control protocol is used by multicast router and host 
    to exchange the multicast services information. Multicast supports 
    dynamic membership but does not support mobile group members. As a 
    result, to provide multicast services for mobile host, both multicast 
    route protocol and multicast control protocol face new challenges.  

                          +---+                  --+ 
            Mobile source | S |--->move            | 
                          +---+                    +-> MLD protocol 
                            |                      | 
                    +-------+--------+             | 
                    |                |           --+ 
         Mobile   +---+            +---+           | 
        Forwarder | R |--->move    | R |           | 
                  +---+            +---+           | 
                    |                |             +-> Multicast 
              +-----+-----+          |             | Route protocol 
              |           |          |             | 
            +---+       +---+      +---+           | 
            | R |       | R |      | R |           | 
            +---+       +---+      +---+         --+ 
                          |                        | 
                  +-------+-------+                | 
                  |       |       |                +-> MLD protocol 
                +---+   +---+   +---+     Mobile   | 
                | H |   | H |   | H |---> Receiver | 
                +---+   +---+   +---+            --+ 
     
                  Figure 1 Mobile multicast classification 

 3.1. General issues 

    Traditional multicast routing protocols have been designed 
    considering static network topology, and the multicast delivery tree 
    is stable and little changed. Figure 1 shows the classification of 
    mobile multicast, including mobile source, mobile receiver or mobile 
    forwarder. Directly applying traditional multicast route protocols to 
    mobile scenario may result in multicast session disruption. To 
    improve the performance of multicast services, it has to solve the 
    following problems.  

  
 Zhang, Guan et al.     Expires January 2, 2008                [Page 4] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 3.1.1. Reconstruction of multicast delivery tree 

    The foundational problem in mobile multicast is the reconstruction of 
    multicast delivery tree. There are two kinds of multicast delivery 
    trees, source-based tree such as DVMRP, MOSPF, PIM-DM and PIM-SSM, 
    and shared tree such as PIM-SM and CBT. Source-based protocols 
    construct multicast delivery trees for every source in a group, while 
    shared tree protocols construct a RP or Core based multicast delivery 
    tree for a group. When we implement mobile multicast, the same mobile 
    types in different multicast delivery tree may have different results.  

 3.1.2. Mobile source issues 

    Once source changes its attachment, it will affect all receivers in 
    the group. Firstly, transparency is the major issue for mobile source. 
    Mobile source should hide the mobility and use the HoA as the source 
    address of multicast data. Otherwise, the foreign network will not 
    forward these packets. However, using the HoA will result in the 
    ingress filtering problem and RPF check failure. Secondly, packet 
    loss has an important impact on the performance of mobile multicast 
    services. Thirdly, when mobile source is out of the range of group, 
    the AR to which mobile source is attached will discard the multicast 
    packets from the mobile source which will be considered as a foreign 
    source.  

 3.1.3. Mobile receiver issues  

    Once receiver changes its attachment, it only affects itself, and 
    causes join delay and packet loss.  

 3.1.4. Mobile forwarder issues  

    Mobile forwarder is the node in the multicast delivery tree. Once 
    forwarder changes its attachment, it will affect the receivers in the 
    multicast route path. Although mostly mobile multicast schemes only 
    focus on the mobility in the access networks, the mobility in the 
    core networks should also be considered forward mobility.  

 3.2. Mobility support specification issues 

    Mobile IP provides handover management and location management for 
    mobile entity, and it sets up the binding cache between HoA and CoA 
    to support the transparent unicast route. But, it does not provide 
    mechanisms to enable multicast session to survive handover and to 
    seamlessly continue from the new location.  

  
 Zhang, Guan et al.     Expires January 2, 2008                [Page 5] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    Firstly, MIPv6 should not only record the unicast binding cache, but 
    also record the multicast binding cache to assist the mobile 
    multicast. Multicast binding cache may include the group address, 
    source lists, filter mode and interface identifier. It gets the 
    membership information through the tunneled MLD messages or extended 
    signaling and gets the MN information from unicast binding cache. The 
    Multicast binding cache can be located in the HA or the other entity 
    such as Rendezvous Point in PIM-SM.  

    Secondly, Multicast session consists of multicast data transmission 
    and multicast group control messages transmission. HA should 
    distinguish the owner of MLD messages from the MN and intercepts and 
    tunnels the global scoped multicast packets on home network based on 
    the multicast group control protocol. MN should send the MLD messages 
    to HA through tunnel or AR through physical interface to receive the 
    multicast data from HA or AR respectively. As described in MIPv6, to 
    support mobile multicast, HA should be a full IPv6 multicast router 
    or have the proxy MLD function coupled with kernel multicast 
    forwarding. However, MIPv6 does not define the detailed mechanisms 
    and the functional requirements for HA and MN. To support the 
    seamless multicast handover, HA should cooperate the MIPv6 with 
    multicast routing protocol or proxy MLD, and sets up the multicast 
    information for MN and transmits the native multicast packets between 
    HA and MN.  

    Thirdly, Mobile IP based mobile multicast schemes have to solve the 
    route optimization problem. BT and RS are two basic mobile multicast 
    methods, but both of them have the disadvantages. Thomas C. Schmidt 
    and Matthias Waehlisch [12] classify mobile multicast methods into 
    three kinds, BT based, RS based and Agent based. BT based methods use 
    the bi-directional tunnel to transmit the multicast data between old 
    location and new location of mobile entity, but result in tunnel 
    convergence problem and additional overheads. Using IP tunnels 
    involves multiple encapsulation and de-capsulation operations which 
    require an extra cost of CPU time and memory, and increase the 
    multicast packet size which causes fragmentation and large bandwidth 
    consumption. [11] RS based methods rejoin the multicast delivery tree 
    in new location, but introduce additional join delay, which includes 
    L2 and L3 handover delay, multicast membership protocol delay, 
    multicast delivery tree computation delay, and the increased 
    propagation delay. It makes the multicast session instantaneous and 
    degrades the performance of multicast services. Agent based methods 
    try to balance between BT and RS, but increase the complexity. It 
    needs more signaling to select the multicast agent and reconstruct 
    the multicast tree for mobile entity.  

  
 Zhang, Guan et al.     Expires January 2, 2008                [Page 6] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 3.3. Multicast control protocol issues 

    IPv6 multicast router uses the MLD as the multicast group control 
    protocol to discovery the multicast listeners, while the host uses 
    the MLD to join and leave the group. MLD protocol is designed for 
    fixed nodes, and only focuses on the dynamic group membership, but 
    not considers the mobility of node. To support the mobile multicast, 
    MLD protocol has to solve the following problems.  

    Firstly, mobile entity has to send unsolicited MLD report message 
    immediately after detecting the movement to shorten the rejoin delay. 
    However, the rejoin delay results in many packets lost unfortunately 
    even without including the link layer and IP layer handover delay. 
    MLD can not maintain multicast group membership continually. As a 
    result, we should increase new MLD message types to support mobile 
    entity.  

    Secondly, MLD messages are link-local, destined to a link-scope 
    multicast address and have a hop limit of 1 and can not forward to 
    the other subnets. When mobile multicast subscriber moves into 
    another subnet, it has to reconstruct MLD states in the new location. 
    However, the MLD protocol does not provide this mechanism. How to 
    transfer the MLD state between old location and new location affects 
    the performance of multicast services.  

    Thirdly, MLD protocol only records the multicast membership 
    information for every link not the node, which can reduce the number 
    of multicast states in shared link such 802.11. But for some point-
    to-point links such as UMTS, HA assigns a home link prefix that is 
    unique for each MN and HoA is assigned from this unique prefix. As a 
    result, it makes a link for each MN. So the multicast behavior could 
    be simplified. Extend the MLD to record MLD state for MN in point-to-
    point link is preferable.  

 3.4. Multi-hop mobile multicast issues 

    The current mobile multicast schemes mainly are single-hop based, and 
    the distance between mobile multicast subscribers and the AR is one 
    hop. However, mobile network multicast especially MANET multicast 
    interworking with the fixed networks is multi-hop. As for the NEMO 
    multicast, the node in the mobile network such as LFN, VMN joins the 
    multicast group through MR which may be multiple hops to the access 
    networks. MLD messages and multicast packets can not be forwarded if 
    the router in the path to AR does not support the multicast function. 
    Especially when nesting happens, the multicast packets transmission 
    will suffers from large overheads and extra propagation delay, which 
    result in degrade of multicast services performance significantly. As 

 Zhang, Guan et al.     Expires January 2, 2008                [Page 7] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    for the MANET multicast interworking with the fixed networks, every 
    node in the MANET may be dynamic and get the connection through 
    multiple nodes as relay points. Because the mobile devices have 
    limited bandwidth, power, and coverage, the multi-hop mobile 
    multicast scheme should be light-weight. How to provide multicast 
    service for these nodes in the mobile network should be considered in 
    the further study. 

 3.5. Multihoming mobile multicast issues 

    Most mobile multicast methods including mobile network multicast are 
    based on single interface and connect to one AR at a time, which 
    results in the mobile entity having to break the connection to the 
    current network before reattaching itself to the new network (Break-
    Before-Mobile) [13]. The reason is that the current wireless 
    interface of mobile devices is incapable of listening to multiple 
    base stations. As a result, the multicast session will be disrupted 
    because of the serious packet loss.  

    Recently, more and more mobile devices have multiple interfaces and 
    can support more than one Internet connections at a time 
    (multihoming). Using multiple interfaces will provide Make-Before-
    Break handoffs [14], ubiquitous access, redundancy, load balancing. 
    However, realizing the multihoming mobile multicast has to consider 
    the problems inheriting from the MIPv6 multihoming [32]. Firstly, to 
    use the multiple interfaces simultaneously, MN should bind multiple 
    CoAs to a given HoA, but the current MIPv6 specification is lacking 
    such ability. Secondly, when multiple paths from and to MN, MN should 
    choose a suitable one to transmit the multicast packets, which 
    includes the interface selection, HoA and CoA selection. Thirdly, 
    when current path fails, MN should redirect the flow to the new path. 
    Final, to balance the multicast traffic among multiple interfaces, MN 
    should set up a load balance mechanism.  

 4. Solutions 

    Mobile IP based mobile multicast solutions include MIPv6 variants 
    extensions, MLD extensions, aiming to support multicast mobility. 
    These extensions usually put the multicast information in signaling 
    or transfer MLD state among ARs to reduce the re-join delay and 
    realize optimal multicast packets transmission.  

  
 Zhang, Guan et al.     Expires January 2, 2008                [Page 8] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 4.1. MIPv6 extensions 

 4.1.1. MIPv6 signaling extensions 

    Most mobile multicast schemes extend the MIPv6 to carry the multicast 
    information in signaling. In basic MIPv6, BT method transmits the MLD 
    messages and multicast packets through the unicast tunnel. Based on 
    RS, F. Xia and B. Sarikaya [15] propose FMIPv6 extension for 
    multicast handover, which introduces a new Multicast Group 
    Information Option (MGIO) in Fast Binding Update (FBU) and Handover 
    Initiate (HI). To reduce the join delay, PAR transmits multicast 
    group information to NAR through FBU and HI with the MGIO to join the 
    multicast group in advance. Then Georigios A. Leoleis et al. [16] 
    propose Fast MIPv6 extensions for Multicast handover support with 
    Flow Tunneling and Buffering (M-FMIPv6/FTB), which uses the 
    conditional tunneling of multicast traffic per flow to solve the 
    tunnel convergence. Besides, it proposes a simple buffering technique 
    to eliminate multicast data loss. More recently, Dong-Hee Kwon et al. 
    [17] proposed an efficient multicast support scheme for FMIPv6. It 
    introduces new multicast options in mobility header and ICMP header, 
    which contain the multicast group information MN subscribed. To 
    reduce the join delay, NAR setups the multicast states MN interested 
    in advance by the FMIPv6 operation. Beside, it establishes a 
    multicast specific tunnel between PAR and NAR instead of the unicast 
    tunnel between PAR and NCoA to solve the tunnel coverage problem. 
    Based on BT, Thomas Schmidt et al. [18] proposed seamless multicast 
    handover in a HMIPv6 environment (M-HMIPv6), which uses the MAP as 
    anchor point for mobile multicast and transmits all multicast data 
    through this MAP using Regional CoA (RCoA) for multicast receiver or 
    source.  

 4.1.2. Multicast route optimization 

    Multicast route optimization aims to solve the tunnel convergence 
    problem and realize the native multicast transmission. Agent based 
    schemes described in [12] mainly focus on these problems. The 
    multicast agent takes over the multicast packets transmission 
    function, and sets up the optimal routing to mobile multicast 
    subscriber. For example, M-FMIPv6 [19] chooses every AR as the agent 
    while M-HMIPv6 chooses the MAP as the agent. DMA [20] chooses the 
    dynamic multicast agent based and distance and movement.  

 4.2. MLD extensions 

    Christophe Jelger and Thomas Noel [23] introduces a new type of MLD 
    message called MLD hold message, which is used to notify an HA to 

 Zhang, Guan et al.     Expires January 2, 2008                [Page 9] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    stop forwarding multicast data for specified group, but keep the 
    group membership. 

    To transfer the multicast state in advance, MN should have the 
    ability to identify whether the AR has the multicast function or not 
    at first. B. Haberman and J. Martin [8] propose Multicast Router 
    Discovery (MRD), a general mechanism to discovery the multicast 
    routers. MRD introduces Multicast Router Advertisement (MRA) and 
    Multicast Router Solicitation (MRS) to detect the IP multicast 
    forwarding ability of a router. MRD protocol can be used in mobile 
    multicast to help the mobile entity to realize the native multicast 
    data transmission. After detecting the multicast ability, the mobile 
    entity should transfer the MLD states to the candidate AR. Based on 
    context transfer [21], I. Miloucheva and K. Jonas [22] propose fast 
    mobile multicast in IPv6 based on multicast listening context 
    transfer method to transmit the MLD states among ARs.  

 4.3. Multi-hop mobile multicast 

    Mobile entity may have multiple Internet connections at the same time 
    and attaches to multiple networks, which have different coverage, 
    bite rate, bandwidth. How to implement mobile multicast in 
    multihoming scenarios may be the key to provide the seamless mobile 
    multicast handover.  

    As for NEMO multicast, C. Janneteau et al. [24] propose MLD-proxy 
    based IPv6 multicast for mobile network, which deploys MLD-based 
    multicast forwarding (MLD-proxying) between MR and visited networks 
    to support the multicast service in mobile network. Kiyong Park et al. 
    [25] propose a dynamic multicast tree construction mechanism for 
    mobile network. It sets up the multicast tunnel between MR and 
    multicast router to support the multicast services.  

    As for the MANET multicast interworking with fixed networks, Wei Ding 
    [26] introduces a Multicast GateWay (MGW) entity to realize multicast 
    routing in the mixed network. MGW has both wire-line multicast 
    interface and wireless communication interface and supports both 
    multicast route protocols. At the beginning it joins the multicast 
    groups on both sides explicitly transmit data packets. However, it 
    has been less focused on the multiple MGWs scenario. Then P. Ruiz and 
    A. Skarmeta propose the Multicast MAnet Routing Protocol (MMARP) [27]. 
    It introduces Multicast Internet Gateway (MIG) and uses the on-demand 
    multicast protocol to construct the multicast structure in the MANET, 
    maintains the route to the MIG. Besides, MMARP supports a standard 
    mobile node accessing the Internet through the MANET. MIG keep the 
    connectivity with the AR through the IGMP inquire message. However, 
    the existed schemes still need further study to solve problems such 

 Zhang, Guan et al.     Expires January 2, 2008               [Page 10] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    as multicast security, management etc. Afterwards Wang et al. propose 
    a Modified MLD (M.MLD) scheme [28] which modifies the MLD messages 
    for MANET to realize the IPv6 multicast between fixed network and 
    MANET. In this scheme the access router in the MANTE is deployed as a 
    Designated Router (DR) of the fixed network, and M.MLD is used as the 
    multicast membership management protocol in the MANET by 
    encapsulating in the unicast packets. More recently, IETF MANET WG 
    proposes a Simplified Multicast Forwarding (SMF) for MANET [29] and 
    tries to support interoperability with connected wired infrastructure. 
    Zhang hui et al. [30] proposes a multicast interworking scheme 
    between MANET and fixed network which supports cross-network 
    multicast sessions. It uses the Certificate Authority (CA) [31] to 
    manage the cross-network multicast sessions and insure the multicast 
    security.  

 4.4. Multihoming mobile multicast 

    Current most mobile multicast schemes based on single interface to 
    perform multicast handover, which is less stable and reliable. Once 
    MN or MR lost its connection to Internet, it will have a significant 
    impact on performance of mobile multicast. Recently, the multihoming 
    issues in MIPv6 [32] [33] and NEMO [34] were discussed. MN with 
    multiple addresses which allocated to either a single interface or 
    multiple interfaces can provide ubiquitous, permanent and fault-
    tolerant access to the Internet.  

    Zhang et al. [35] propose a multiple interfaces mobile multicast 
    scheme in Mobile IPv6 and NEMO. The interfaces in the MN may be 
    homogeneous or heterogeneous. This scheme introduces an interface 
    multicast state transition mechanism and multiple interfaces handover 
    mechanism for mobile multicast listeners and mobile multicast sources 
    to support seamless mobile multicast handover.  

 5. Security Considerations 

    This memo discusses the MIPv6 extensions for mobile multicast. 
    Security issues arise from the extensions of mobility support 
    specifications and MLD protocols.  

 6. IANA Considerations 

    There are no IANA considerations introduced by this memo. 

 7. Conclusions 

    This memo discusses the problems arise from the mobile multicast over 
    MIPv6 variants, and describes some solutions.  

 Zhang, Guan et al.     Expires January 2, 2008               [Page 11] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 8. Acknowledgments 

    The authors would like to thank Behcet Sarikaya (Huawei USA), Hesham 
    Soliman (Elevate Technologies), Si-Dong Zhang (BJTU NGIRC) for their 
    valuable comments and suggestions on this memo. 

  
 Zhang, Guan et al.     Expires January 2, 2008               [Page 12] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 9. References 

 9.1. Normative References 

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

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

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

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

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

    [6]  S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 
          August 1989. 

    [7]  Bill Fenner, Mark Handley etc, "Protocol Independent Multicast-
          Sparse Mode (PIM-SM): Protocol Specification (Revised) ", RFC 
          4601, August 2006. 

    [8]  B. Haberman and J. Martin, "Multicast Router Discovery", RFC 
          4286, December 2005.  

 9.2. Informative References 

    [9]  R. Koodli, "Fast Handovers for Mobile IPv6", RFC 4068, July 
          2005. 

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

    [11] Romdhani, I., Kellil, M., Lach, H.-Y. et al., "IP Mobile 
          Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), 
          2004. 

    [12] Thomas C. Schmidt, Matthias Waehlisch, "Multicast Mobility in 
          MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-
          mmcastv6-ps-00, May 2007. 

  
 Zhang, Guan et al.     Expires January 2, 2008               [Page 13] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    [13] Petander H., Perera E., Seneviratne A., "Multiple Interface 
          Handoffs: A Practical Method for Access Technology Independent 
          Make-Before-Break Handoffs", NICTA Technical Report, July 2005, 
          http://nicta.com.au/uploads/documents/PA005092_NICTA1.pdf 

    [14] H. Matsuoka, T. Yoshimura, and T. Ohya, "A robust method for 
          soft IP handover", IEEE Internet Computing, vol 7, no.2, pp 18-
          24, 2003. 

    [15] F. Xia, B. Sarikaya, "FMIPv6 extension for multicast Handover", 
          draft-xia-mipshop-fmip-multicast-00, work in progress, 
          September 2006. 

    [16] Georgios A. Leoleis et al., "Seamless multicast mobility 
          support using fast MIPv6 extensions", Computer Communications 
          (2006), doi: 10.1016/j.comcom. 2006.07.013. 

    [17] Dong-hee Kwon et al., "Design and Implementation of An 
          Efficient Multicast Support Scheme for FMIPv6", IEEE INFOCOM, 
          2006. 

    [18] Thomas C. Schmidt, Matthias Waehlisch, "Seamless Multicast 
          Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", 
          draft-schmidt-waehlisch-mhmipv6-04, Expired, November 2005. 

    [19] K. Suh, Y.-J. Suh, "Fast Multicast Protocol for Mobile IPv6 in 
          the Fast Handovers Environment", IETF Internet Draft, draft-
          suh-mipshop-fmcast-mip6-00, Expired  January 2004. 

    [20] Zhang, Hongke et al., "Mobile IPv6 Multicast with Dynamic 
          Multicast Agent", draft-zhang-mipshop-multicast-dma-03, 
          work in progress, January 2007. 

    [21] J. Loughney et al., "Context Transfer Protocol (CXTP)", RFC 
          4067, July 2005.  

    [22] I. Miloucheva and K. Jonas, "Multicast Contexe Transfer in 
          mobile IPv6", draft-miloucheva-mldv2-mipv6-00, June 2005. 

    [23] Jelger C. and Noel T., "Multicast for Mobile Hosts in IP 
          Networks: Progress and Challenges", Wireless Communications, 
          IEEE, Volume 9, Issue 5, pp 58-64, Oct. 2002.  

    [24] C. Janneteau et al., "IPv6 Multicast for Mobile Networks with 
          MLD-Proxy", draft-janneteau-nemo-multicast-mldproxy-00, Expired, 
          April 2004. 

 Zhang, Guan et al.     Expires January 2, 2008               [Page 14] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

    [25] Kiyong Park et al., "Dynamic Multicast Tree Construction for 
          NEMO", draft-park-nemo-dyn-multicast-tree-00, Expired, Oct. 
          2005.  

    [26] Wei Ding, "Multicast Routing in Fixed infrastructure and mobile 
          ad hoc wireless networks with a multicast gateway" Available: 
          http://kunz-pc.sce.carleton.ca/Thesis/WeiThesis.pdf, 2002.  

    [27] P. Ruiz, A. Skarmeta, "Integrated IP multicast in mobile ad hoc 
          networks with multiple attachments to wired IP networks", Proc. 
          of IEEE International Symposium on Personal, Indoor and Mobile 
          Radio Communications (PIMRC), pp579-583, September 2004. 

    [28] WANG Liang you et al., "Realization of IPv6 Multicast 
          Interworking between MANET and Fixed Networks", The Journal of 
          China Universities of Posts and Telecommunications Vol.10, No.3, 
          pp30-34 Sep. 2003. 

    [29] J. Macker (NRL) et al., "Simplified Multicast Forwarding for 
          MANET", draft-perkins-manet-smurf-02, Work in Progress, IETF 
          MANET work group, 2006. 

    [30] Hui Zhang, Hongke Zhang et al., "A New Architecture of 
          Multicast Interworking between MANET and Fixed Network", 
          Journal of Internet Technology, vol. (8):1, 2007. 

    [31] Al-Sulaiman et al., "Cooperative caching techniques for 
          increasing the availability of MANET certificate authority 
          services", The 3rd ACS/IEEE International Conference on 
          Computer Systems and Applications, pp88-94, 2005. 

    [32] N. Montavount, R. Wakikawa, T. Ernst et al., "Analysis of 
          Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-
          02, work in progress, February 2007.  

    [33] Ernst, T., "Motivations and Scenarios for Using Multiple 
          Interfaces and Global Addresses", draft-ietf-monami6-
          multihoming-motivation-scenario-01, work in progress, Oct. 2006.  

    [34] C. Ng, T. Ernst, E. Paik, M. Bagnulo, "Analysis of Multihoming 
          in Network Mobility Support", draft-ietf-nemo-multihoming-
          issues-07, work in progress, February 2007. 

    [35] Zhang Hongke et al., "Multiple Interface Mobile Multicast", 
          draft-zhang-monani6-multipleif-mcast-00, work in progress, July 
          2007. 

 Zhang, Guan et al.     Expires January 2, 2008               [Page 15] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 Author's Addresses 

    Hong-ke Zhang, Jian-feng Guan, De-yun Gao, Hua-chun Zhou, Ya-juan Qin 
    Next Generation Internet Research Center (NGIRC), Beijing JiaoTong 
    University  
    Beijing, China, 100044 
       
    Phone: +86 10 51685677 
    Email: [email-masked] 
           [email-masked] 
           [email-masked] 
           [email-masked] 
           [email-masked] 

 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 
    [email-masked]. 

 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, The IETF TRUST AND 
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS  
    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED    
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

 Zhang, Guan et al.     Expires January 2, 2008               [Page 16] 
     
 Internet-Draft               MEMCAST-PS                      July 2007 

 Copyright Statement 

    Copyright (C) The IETF Trust (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. 

  
 Zhang, Guan et al.     Expires January 2, 2008               [Page 17] 

　　　　　　　
											 Tony
　　　　　　									[email-masked]
　　　　　　									　　　　2007-07-04	

_______________________________________________
multimob mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimob