[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IETF MIPSHOP Working Group                                  Kyungjoo Suh
Internet Draft                                       Samsung Electronics
                                                           Dong-Hee Kwon
                                                           Young-Joo Suh
                                                                 POSTECH
                                                           Youngjun Park
                                                     Samsung Electronics

Document: draft-suh-mipshop-fmcast-mip6-00.txt
Expires: July 2004                                          January 2004



                  Fast Multicast Protocol for Mobile IPv6
                    in the fast handovers environments


Status of This Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.


Abstract


    This document defines the Fast Multicast Protocol for Mobile IPv6
    [2] in the Fast Handovers environments whereby a mobile node (MN)
    can receive multicast data with reduced loss and delay after
    handoffs. The proposed protocol can be implemented by the simple
    modification of the Fast Handovers protocol [1] so that it can be
    easily applied to the Fast Handovers for Mobile IPv6. This document
    does not need a certain assumption of a specific multicast routing
    protocol, so that any existing multicast routing protocol can be
    used with the proposed protocol.







Suh, et al                                                        [Page 1]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6   January 2004

Table of Contents

1. Introduction   . . . . . . . . . . . . . . . . . . . . . . . . . .  3

2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3

3. Overview of Fast Multicast protocol  . . . . . . . . . . . . . . .  4

4. Fast Multicast Protocol Operation  . . . . . . . . . . . . . . . .  5

    4.1 Fast Multicast in Predictive Fast Handovers environment . . .  7

    4.2 Fast Multicast in Reactive Fast Handovers environment . . . .  8

    4.3 Message Format in Fast Multicast protocol   . . . . . . . . .  9

        4.3.1 Modified PrRtAdv Message Format . . . . . . . . . . . .  9

        4.3.2 MH Multicast Address Option Format  . . . . . . . . . . 10

        4.3.3 ICMP Multicast Address Option Format  . . . . . . . . . 11

5. Security Consideration . . . . . . . . . . . . . . . . . . . . . . 12

Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . . . 12

References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . . 12

























Suh, et al                                                        [Page 2]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004


1. Introduction

    Mobile IP has been proposed to provide a seamless connection when
    a MN changes the point of attachment to the network. In general,
    in the basic Mobile IPv6 [2], the multicast data delivery schemes
    are defined in addition to the unicast data delivery. In the Mobile
    IP, some packets for the MN may be lost when a MN handoffs between
    two access routers. Although the Fast Handovers protocol [1] is
    proposed to reduce such loss and delay, it focuses on the unicast
    data delivery. This means the Fast Handovers protocol cannot
    reduce the multicast data loss and delay during MN's handoffs.

    If a MN wants to receive a multicast data, it should subscribe to
    a corresponding multicast group. When a MN handoffs to a new
    network that does not subscribe to a multicast group in which a MN
    interests, it should initiate a procedure to subscribe to a
    multicast group after finishing a handoff procedure. The fact
    causes a multicast data loss and delay.

    This document describes a Fast Multicast protocol to reduce a
    multicast data loss and delay. In the proposed protocol, a MN sends
    the information about a multicast group to which MN subscribes, to
    the current access router before a MN handoffs to another network.
    After receiving this information, the current access router sends
    this information to the nearby access router to which the MN will
    handoff in order to subscribe to a multicast group. When the MN
    handoffs to another network, the access router of the network can
    deliver multicast data packets to the MN, because it already
    subscribes to a multicast group. Therefore the MN can receive
    multicast data with reduced loss and delay after handoffs. The
    proposed protocol can be implemented by the simple modification of
    Fast Handovers protocol [1] so that it can be easily applied to Fast
    Handovers protocol for Mobile IPv6.

2. Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as describe in RFC 2119.

    In this document, some terminologies are same as defined in the
    Fast Handovers protocol [1] such as MN, AR, NAR, PAR, RtSolPr,
    PrRtAdv, HI, Hack, FBU, FBack, FNA, etc. The following terminologies
    are used in this document.

    Multicast Service

       One to many communication service by which a node joining in a
       specific multicast group can receive data from a multicast
       sender.



Suh, et al                                                       [Page 3]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004


    Multicast Latency

       The time difference between when a MN is last able to send
       and/or receive a multicast data packet by way of the PAR, and
       when the MN is able to send and/or receive a multicast data
       packet through the NAR.

3. Overview of Fast Multicast protocol

    Fast Multicast protocol presents MNs with a fast and seamless
    multicast data delivery by exchanging information related to a
    multicast group between ARs (PAR and NAR). By Fast Multicast
    operations, a NAR can learn, in advance, the information on a
    multicast group in which the MN interests. The main goal of the
    Fast Multicast is minimizing the Multicast Latency that is
    required when a MN moves from one AR to another while receiving
    a Multicast Service. The Fast Multicast can be applied to the Fast
    Handovers protocol with slight modification. Furthermore, the Fast
    Multicast is independent of multicast routing protocols.

    If a MN wants to receive a Multicast Service continuously after
    handoffs to a network managed by NAR, the Fast Multicast protocol
    lets a NAR subscribe to a multicast group, in advance, before the
    MN handoffs to its network. During a Fast Handovers protocol
    process, MN sends a FBU message to a PAR with new multicast address
    option. The new multicast address option contains a multicast
    address(es) which a MN subscribes to and wants to receive a
    multicast service after handoffs to a NAR network. After receiving
    a FBU message, a PAR exchanges HI/Hack messages between a NAR and
    itself. A PAR sends multicast address option when it sends a HI
    message to a NAR. A NAR subscribes to a multicast group contained
    in the multicast address option when receiving a HI message. If a
    NAR refuses to subscribe to a multicast group, it sends that
    information to a PAR with HAck message and a PAR to a MN with FBack
    message. Through this procedure, a MN can receive a multicast data
    from the NAR when it completes a Fast Handovers procedure.

    If there are some multicast groups that a NAR refuses to subscribe
    to, a MN receives a multicast data from a PAR using established
    tunnel between a PAR and a NAR. When a multicast receiver is a MN
    which handoffs to a neighbor network, a PAR forwards a MLD Query
    message to the MN using tunnel between a PAR and a NAR. If the MN
    replies to the MLD Query message with a MLD Report message, a PAR
    forwards a multicast data packet to the MN. Therefore the MN can
    receive a multicast data packet.








Suh, et al                                                       [Page 4]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004


4. Fast Multicast Protocol Operation

    Figure 1 and Figure 2 show a Fast Multicast protocol operation in
    a Predictive and Reactive Fast Handovers environment.

    In the Fast Multicast protocol, one new flag and two new options
    are defined as followings:

    Multicast Service (M) bit
       It indicates whether the AR which a MN requests a L3 information
       in a RtSolPr message supports a multicast service or not.

    Mobility Header Multicast Address Option
       It is a new mobility header option which contains a multicast
       address(es) that a MN subscribes to. It is refered as MH
       Multicast Address Option in this document. The format of this
       option is defined in section 4.3.

    ICMPv6 Multicast Address Option
       It is a new ICMPv6 option which contains a similar information
       of a Mobility Header Multicast Address Option. The proposed
       protocol also defines a new ICMPv6 option that has similar
       information because HI and HAck messages of a Fast Handovers
       protocol are delivered using ICMPv6. It is refered as ICMP
       Multicast Address Option in this document. The format of this
       option is defined in section 4.3.

    In a Predictive Fast Handovers protocol, when the PAR receives a FBU
    message, it knows that the MN handoffs soon and informs the NAR of
    this information through the exchange of HI and HAck messages. The
    PAR includes ICMP Multicast Address Option in the HI message to
    transmit a multicast address(es) if a MN wants to receive a
    Multicast Service in a network managed by NAR. The NAR receiving HI
    message transmits HAck message with an ICMP Multicast Address Option
    which informs whether it supports requested Multicast Service or not.
    If the NAR accepts a request, it joins a multicast group(s). The PAR
    receiving HAck message copies the multicast address(es) in the ICMP
    Multicast Address Option to the MH Multicast Address Option in the
    FBack message, and sends the message to the MN to inform the MN of
    success or failure of the Multicast Service request. Therefore,
    the MN knows success or failure of Multicast Service request when
    receives the FBack message. If Multicast Service request succeeds,
    the MN informs the NAR of its arriving after handoffs by sending
    FNA message with MH Multicast Address Option. The MH Multicast
    Address Option in the FNA message requests the NAR to forward the
    multicast data to the MN.

    In a Reactive Fast Handovers protocol, the MN does not receive FBack
    message on the PAR network. The MN sends FNA message as soon as it
    attaches to the NAR with FBU message. In order to enable the NAR to



Suh, et al                                                       [Page 5]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004

    MN                         PAR                       NAR
     |                          |                         |
     |--------RtSolPr---------->|                         |
     |<----- PrRtAdv(M bit) ----|                         |
     |                          |                         |
     |-----------FBU----------->|----------HI------------>|
     |  (MH Multicast Option)   | (ICMP Multicast Option) |
     |                          |                      Join to
     |                          |                     Multicast
     |                          |                       Group
     |                          |<--------HAck------------|
     |                          | (ICMP Multicast Option) |
     |                          |                         |
     |           <----FBack-----|----FBack----->          |
     |   (MH Multicast Option)  |  (MH Multicast Option)  |
     |                          |                         |
  disconnect                  forward                     |
     |                        packets====================>|
     |                          |                         |
     |                          |                         |
  connect                       |                         |
     |                          |                         |
     |------------- FNA (MH Multicast Option) ----------->|
     |<=============================================== deliver
     |                          |                      packets
     |                          |                         |

       Figure 1: Fast Multicast in Predictive Fast Handover

    MN                         PAR                       NAR
     |                          |                         |
     |--------RtSolPr---------->|                         |
     |<----- PrRtAdv(M bit) ----|                         |
     |                          |                         |
  disconnect                    |                         |
     |                          |                         |
  connect                       |                         |
     |                          |                         |
     |-------- FNA[FBU(MH Multicast Option)] ------------>|
     |                          |                      Join to
     |                          |                     Multicast
     |                          |                       Group
     |                          |<-------- FBU -----------|
     |                          |                         |
     |                          |-------- FBack --------->|
     |                          |                         |
     |                        forward                     |
     |                        packets====================>|
     |                          |                         |
     |<=============================================== deliver
     |                          |                      packets
     |                          |                         |

       Figure 2: Fast Multicast in Reactive Fast Handover

Suh, et al                                                      [Page 6]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004

    forward packets immediately (when FBU message has been processed),
    the MN encapsulates FBU message in FNA message. The exchange
    procedure of the FBU and FBack message between PAR and NAR is
    defined in the Fast Handovers protocol. The NAR subscribes to a
    multicast group using the multicast address informed by the MH
    Multicast Address Option. Except this, other operations are same
    as defined in the Fast Multicast protocol when the Predictive Fast
    Handovers Protoocl is used.

4.1 Fast Multicast in Predictive Fast Handovers environment

    All description of this section makes use of Figure 1 as the
    reference.

    When a MN determines to handoff soon, it sends a RtSolPr message
    to a PAR as defined in the Fast Handovers protocol. In response,
    the PAR sends a PrRtAdv message including M bit that represents
    whether the corresponding NAR supports a Multicast Service or not.
    The method by which Access Routers exchange information about the
    Multicast Service support of their neighbors is outside the scope
    of this document. If the NAR supports a Multicast Service, this
    bit SHOULD be set to 1. With the information provided in the
    PrRtAdv message, the MN knows whether the NAR can support a
    Multicast Service or not. If the MN does not interest in a
    Multicast Service, it silently ignores the M bit. After then the
    MN sends a FBU message including a MH Multicast Address Option.
    The purpose of MH Multicast Address Option is to inform the PAR
    of the multicast address(es) which a MN subscribes to.

    The PAR receiving a FBU message with a MH Multicast Address Option
    SHOULD send the HI message to the NAR with an ICMP Multicast
    Address Option which is derived from the MH Multicast Address Option
    of the FBU message. Through ICMP Multicast Address Option in a HI
    message, the NAR knows that the MN wants to receive a Multicast
    Service after handoffs. Therefore the NAR checks whether it can
    support Multicast Service or not. If the NAR cannot support a
    requested Multicast Service, it SHOULD send the HAck message to the
    PAR with an ICMP Multicast Address Option. The purpose of this ICMP
    Multicast Address Option is to inform the MN of the multicast
    address(es) that the NAR cannot subscribe to. When the NAR can
    support of some of multicast Services, only address(es) that the
    NAR refused to subscribe is included in the ICMP Multicast Address
    Option. Therefore there is no ICMP Multicast Address Option if the
    NAR can support all of the Multicast Service requested in
    the ICMP Multicast Address Option of a HI message.

    The NAR also joins the multicast group to which it subscribe for
    supporting MN. The method by which the NAR joins to a multicast
    group is outside the scope of this document. After the PAR receives
    a Hack Message from the NAR, it sends a FBack message to the MN.
    This message also includes the MH Multicast Adddress Option derived
    from the ICMP Multicast Address Option of the HACK message. The
    purpose the MH Multicast Address Option is the same as the ICMP

Suh, et al                                                       [Page 7]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004



    Multicast Address Option of the Hack Message.

    If the MN receives FBack message without MH Multicast Address Option
    the NAR can support all of the Multicast Service requested by the MN.
    In that case, the MN sends a FNA message with MH Multicast Address
    Option which the MN wants to subscribes to after complete the
    handover procedure. Through the multicast address(es) of this
    option, the NAR can send multicast data to the MN.

    If the NAR refuses the MN's request, the MN cannot receive a
    Multicast Service at the NAR's network after handoffs. In this
    case, some other methods are required to support seamless Multicast
    Service. In the proposed protocol, the PAR forwards a multicast
    data to the MN using tunnel between the PCoA and the NCoA. The ICMP
    MLD protocol is assumed to manage multicast group members in the
    proposed protocol.

    The PAR sends periodically an ICMP MLD Query message to its network.
    If a multicast receiver exists in a different network, the PAR
    forwards an ICMP MLD Query message to a remote multicast receiver
    (e.g. MN) when the tunnel exits. In the proposed protocol, the
    tunnel is created between a PCoA and a NCoA as defined in the Fast
    Handovers protocol. When the MN receives a MLD Query message from
    the PAR through a tunnel, it sends a MLD Report message in response
    to a MLD Query message if it wants to receive a Multicast Service
    from the PAR.

    When the PAR receives multicast data, it checks whether the tunnel
    exists between the PCoA and the NCoA, and then checks whether it
    should forward the multicast data through the tunnel or not. The PAR
    forwards a multicast data through the tunnel when the tunnel exists
    and there is a multicast receiver. Based on these procedures, the MN
    can receive seamless Multicast Service within the network where the
    Multicast Service is not supported.

    This method can be also applied to a case in which the NAR accepts
    a Multicast Service but the join procedure has not been finished yet
    after MN's handover. In this case, the MN replies to the MLD Query
    Message from the PAR by the MLD Report message to maintain tunnel
    until the join procedure is finished. Therefore the MN can receive
    multicast data from the PAR. When the join procedure is finished,
    the NAR starts to send the MLD Qurey message and the MN sends a MLD
    Report message in response. As the MN replies to the MLD Query
    message from the PAR by the MLD Done message, the PAR does not
    forward the multicast data to the MN any more.

4.2 Fast Multicast in Reactive Fast Handover environment

    All description of this section makes use of Figures 2 as a
    reference.


Suh, et al                                                       [Page 8]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004

    In the Reactive Fast Handover protocol, the MN does not receive a
    FBack message at the PAR's network. Therefore the MN should send
    immediately a FNA with FBU message when it detects an attachment to
    a NAR's network. The MN also sends a MH Multicast Address Option in
    the FBU message. When the NAR receives a FNA with FBU message from
    a MN, it sends a FBU message included in the FNA message to the PAR.
    Before the NAR sends a FBU message to the PAR, it joins to a
    multicast group(s) which a MN requests to subscribe to. The PAR
    sends a FBack message to the NAR in response to the FBU message.
    In addition, the PAR forwards a MLD Query message to the MN. Through
    this procedure, the MN can receive a Multicast Service at the NAR
    network when the Reactive Fast Handovers protocol is used.

4.3 Message Formats in Fast Multicast protocol

    Basic message formats of the proposed Fast Multicast Protocol are
    the same as defined in the Fast Handovers protocol. Only the PrRtAdv
    message is slightly modified. The proposed protocol also defines
    new MH Multicast Option and ICMP Multicast Option.

4.3.1 Modified PrRtAdv Message Format

    The Proposed protocol modifies the format of PrRtAdv message by
    adding a single flag bit in the Reserved field to indicate whether the
    neighbor AR which a MN request in RtSolPr message
    supports multicast service or not. When the MN does not interest
    in a multicast service, it silently ignores this bit. The format of
    the PrRtAdv Message is as follows:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Identifier           |M|          Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Options ...
    +-+-+-+-+-+-+-+-+-+-+-+-


    This format represents the following changes over that originally
    specified in the Fast Handovers protocol[1]:

    Multicast Service (M)

    The Multicast Service (M) bit is set in PrRtAdv message to indicate
    that the AR which MN requests in RtSolPr message also supports
    multicast service





Suh, et al                                                      [Page 9]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004

    Reserved

       Reduced from a 16-bits field to a 15-bits field on account of
       the addition of the above bit

    The PrRtAdv message MAY have options. These options MUST use the
    Option format defined in Fast Handovers [1].

4.3.2 MH Multicast Address Option Format

    The proposed protocol defines a new mobility option, Multicast
    Address option, that can be used in a FBU and FNA messages to
    indicate the multicast address(es) which a MN wishes to subscribe
    to. The format of the MH Multicast Address option is as follows:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |    Length     |    Number     |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      Multicast Address                        +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Type

       TBA

    Length

       8-bit unsigned integer, representing the length in octets of the
       mobility options, not including the Type and Length field

    Number

       Number of the multicast address which presents in Multicast
       Address field.

    Reserved

       Must be set to zero by the sender and ignored by the receiver.

    Multicast Address

       Multicast address which a MN currently subscribes to. MAY be more
       than one because MN can subscribe to several multicast addresses.

Suh, et al                                                      [Page 10]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004


4.3.3 ICMP Multicast Address Option Format

    The proposed protocol defines a new ICMPv6 option, Multicast Address
    option, used in a HI and HAck messages. In the HI messages, this
    option notifies a NAR of the multicast address(es) which a MN
    continuously wants to subscribe to after connected to NAR's network.

    In the HAck message, this option notifies a PAR, a NAR through a
    FBack message, of the multicast address(es) which a NAR cannot
    support. The format of the ICMP Multicast Address option is as
    follows:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Sub-Type   |    Number     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Multicast Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Type

       TBA

    Length

       8-bit unsigned integer, representing the length in octets of the
       mobility options, not including the Type and Length field

    Sub-Type

       0

    Number

       Number of the multicast address which presents in Multicast
       Address field.

    Multicast Address

       Multicast address which is copied from Fast Binding Update. MAY
       be more than one because MN can send Fast Binding Update to PAR
       with several multicast addresses.


Suh, et al                                                     [Page 11]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004


5. Security Considerations

    The security considerations resulting from the use of this framework
    do not offer any higher level of security in basic mobile IP
    operation. Therefore, in the next version of this document will
    include an appropriate level of security for Fast Multicast protocol.

Acknowledgements

  The authors would like to acknowledge the contribution from Woo-Jae Kim
  to improve this specification.


References

    [1] Rajeev Koodli, "Fast Handovers for Mobile IPv6", Internet Draft,
        draft-ietf-mipshop-fast-mipv6-00.txt, October 2003

    [2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
        draft-ietf-mobileip-ipv6-24.txt, June 2003

    [3] C.perkins, "IP Mobility Support for IPv4", RFC3344, August 2002

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


Author's Address

   Questions about this memo can be directed to:

     Kyungjoo Suh (Joo Suh)
        Global Standards and Strategy team
        Telecommunication R & D Center
        Samsung Electronics Co., LTD.
        Dong Suwon P.O. BOX 105,
        416, Maetan-3dong, Youngtong-gu,
        Suwon-city, Gyeonggi-do, 442-600
        Korea
        Phone: +82-31-279-5123
        Email: joo.suh@samsung.com
        Fax: +82-31-279-5130


     Dong-Hee  Kwon
        POSTECH
        Dept. of Computer Science and Engineering
        Pohang, KOREA
        Phone: +82-54-279-5671
        E-Mail: ddal@postech.edu
        Fax:   +82-54-279-5699


Suh, et al                                                     [Page 12]


INTERNET-DRAFT   Fast Multicast Protocol for Mobile IPv6    January 2004

    Young-Joo   Suh
        POSTECH
        Dept. of Computer Science and Engineering
        Pohang, KOREA
        Phone: +82-54-279-2243
        E-Mail: yjsuh@postech.edu
        Fax:   +82-54-279-5699

      Youngjun Park
        Global Standards and Strategy team
        Telecommunication R & D Center
        Samsung Electronics Co., LTD.
        Dong Suwon P.O. BOX 105,
        416, Maetan-3dong, Youngtong-gu,
        Suwon-city, Gyeonggi-do, 442-600
        Korea
        Phone: +82-31-279-5979
        Email: youngjun74.park@samsung.com
        Fax: +82-31-279-5130



































Suh, et al                                                       [Page 13]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/