I. Miloucheva,
Internet Draft                                               K. Jonas
Expires: December 10, 2005                                     SATCOM
                                                         June 8, 2005

               Multicast Context Transfer in mobile IPv6

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.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Protocol mechanisms for fast mobile multicast in IPv6 based on multicast
   listening context transfer are proposed.
   The focus is the context transfer for mobile multicast listeners using
   Multicast Listener Discovery protocol Version 2 (MLDv2).
   Multicast context transfer block and operational considerations for
   optimised multicast context transfer based on Fast Handovers for Mobile
   IPv6 and Candidate Access Router Discovery are described.
   The requirements for MLDv2 context extension and operation at access

Miloucheva            Expires December 10, 2005                    [Page 1]

INTERNET-DRAFT       Multicast context transfer in MIPv6          June 2005

   routers to support multicast context transfer for mobile IPv6 are
   Interactions of MLDv2 with Protocol Independent Multicast Sparse Mode
   (PIM-SM) for multicast routing state update based on multicast
   listening context transfer are overviewed.
   Operational considerations for MLDv2 and PIM-SM to support multicast
   receiver and source mobility based on context transfer are discussed.
   Comparison with other multicast protocol proposals for Mobile IPv6
   (MIPv6) is given.

Table of Contents

   1.   Introduction ...................................................  2
   2.   Terminology used in this document ..............................  3
   3.   Multicast context transfer .....................................  4
     3.1 Protocol overview .............................................  4
     3.2 Multicast context transfer block ..............................  6
     3.3 Optimised multicast context transfer ..........................  7
        3.3.1 Multicast context transfer for IPv6 Fast Handovers .......  7
        3.3.2 Multicast support with CARD protocol .....................  9
   4.   Requirements for IPv6 listening and routing protocols .......... 10
     4.1 Requirements for MLDv2 ........................................ 10
         4.1.1. MLDv2 context extension ................................ 10
         4.1.2 Operational considerations .............................. 11
     4.2 Requirements for Multicast routing (PIM-SM) ................... 12
   5.   Comparison with other mobile multicast protocols for IPv6 ...... 12
   6. IANA considerations .............................................. 13
   7. Further work ..................................................... 13
   References .......................................................... 13
   Author's Addresses................................................... 15

1. Introduction

   Context transfer is proposed for mobile nodes for quickly
   re-establishment of their services when the nodes move and change their
   access routers [13].

   The Context Transfer protocol (CTP) [6] designed by the IETF
   Seamoby WG as Experimental protocol for usage in Mobile IPv4 and MIPv6
   environment is aimed to provide general mechanisms for exchange of
   context data for moving mobile nodes between access routers.
   In the Appendix B of CTP specification [6], an example for multicast
   listener context transfer in IPv6 considering MLD [RFC2710] is given.
   In this example, for each active multicast group at the access router
   MLD context is established.
   Because the access routers does not distinguish between MLD contexts of
   individual nodes, all MLD contexts established for subscribed multicast
   group addresses, which are attached to a given link at the previous
   access router, are transferred to the next router during the handover.

Miloucheva            Expires December 10, 2005                    [Page 2]

INTERNET-DRAFT       Multicast context transfer in MIPv6          June 2005

   This causes additional network overhead and processing for creation of
   multicast contexts and route trees at the next access routers for
   multicast groups, which are not needed for the particular moving node.

   The focus of the current draft is the efficient multicast context transfer
   considering the Multicast Listener Discovery Protocol (MLDv2) in mobile
   IPv6 (MIPv6) environment.
   It is aimed to support seamless handover for mobile receivers using MLDv2
   in case of Any Source [21] and Source Specific Multicast [24].

   The work is based on the European project DAIDALOS [14], which goal is
   heterogeneous mobile networking including DVB-T and unidirectional links

   The multicast context transfer in DAIDALOS is designed to support
   applications, such as:
   - Multicast file and streaming distribution
   - Multiparty conference scenarios
   - Multicast audio and video transmission
   - DVB-T.

   Mobile multicast in this framework is based on MLDv2 context transfer for
   mobile multicast receivers [17].

   This Draft defines the multicast context transfer operations and data
   structures required for MLDv2 service re-establishment in Mobile IPv6.
   Facilities for optimised multicast context transfer based on the Fast
   Handovers proposal for MIPv6 [5] and Candidate Access Router Discovery
   (CARD) protocol [7] are overviewed.

   Requirements for MLDv2 operation in case of context transfer and extension
   of MLDv2 protocol context at access routers to track information per
   individual nodes and their multicast groups are descried.
   The interaction of MLDv2 and PIM-SM to support context transfer is

   The fast mobile multicast using context transfer is compared with other
   multicast solutions for IPv6 based on Fast Handovers for Mobile IPv6
   [8] and Hierarchical Ipv6 Environment [9].

2. Terminology used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in [9].
   Mobility related terminology is defined in [10].

   The Internet Protocol (IP) multicast service model for any source multicast
   (ASM) is defined in RFC 1112 [21]. Source specific multicast (SSM)

Miloucheva            Expires December 10, 2005                    [Page 3]

INTERNET-DRAFT       Multicast context transfer in MIPv6          June 2005

   provides network-layer support for one-to-many delivery only and is
   defined in [19], [24], [23], [22].
   Multicast Listener Discovery Version (MLDv2) for IPv6 is defined in [1] as
   extension of MLD [2]. PIM-SM is specified in [3], [4].
   Abbreviations used in the following text:

       AR     Access Router
       MN     Mobile Node
       CTP    Context Transfer Protocol
       M-CTB  Multicast Context Transfer Block
       ASM    Any Source Multicast
       SSM    Source Specific Multicast
       FBU    Fast Binding Update

3. Multicast context transfer

3.1. Protocol overview

   The multicast context transfer is used in case of mobile node movement
   (handover) to provide and install the listening and routing control data
   for the multicast groups required for the active multicast services of
   the mobile node.
   Considering the Context Transfer Protocol's messages and signalling flows
   [6], the context transfer for mobile multicast in IPv6 is defined.

   Multicast listening in IPv6 is based on MLDv2 [1], which extends the MLD
   protocol [2] for Source Specific Multicast [19].
   For multicast routing, MLDv2 provides the information on the active
   listeners of a particular multicast group to the multicast routing
   protocol. In this draft, PIM-SM [3], [4] is considered.

   Dependent on the time of the context transfer activation, the context
   transfer could be based on:
   - predictive signalling: context transfer starts before the handover,
     when the mobile node is connected to the previous access network.
   - reactive: context transfer starts after the connection of the mobile
     node to the next access network.

   The predictive and reactive strategies for usage of context transfer
   protocol are described in [6].

   In the predictive scenario for multicast context transfer described in
   figure 1, the mobile node sends a message to the previous
   access router to activate the context transfer.

   Context transfer is started with the context activation by the mobile
   node sending a message to the previous access router.
   According [6], the context transfer initiation could also be based
   on internally generated (link layer 2 triggers).

Miloucheva            Expires December 10, 2005                    [Page 4]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

                  +----------------+         +-----------------+
                  |access network  |         |access network   |
                  +----------------+         +-----------------+
                           |                       |
                           |                       |
               previous AR v                       v  next AR
                   +---------------+           +----------------+
                   | MLDv2 context | M-CTB     | MLDv2 context  |
                   | per node and  | data      | update         |
   context         | aggregated    | --------->|                |
   activate        |               |<--------- |                |
              +--> +---------------+ CT reply  +----------------+
              |            |                        |
              |            |multicast               | multicast
              |            |                        |
              | MN         v                    MN  v
          +-------------------+             +-------------------+
          |MLDv2 socket state |   handover  |MLDv2 socket state |
          |-------------------|   ------>   |-------------------|
          |                   |             |                   |
          +-------------------+             +-------------------+

   Figure 1: Predictive scenario for multicast context transfer

   After the context activation, the multicast context transfer block
   (M-CTB) is built at the previous access router in interaction with MLDv2.

   The M-CTB includes the  multicast addresses required for the multicast
   services of the moving mobile node. M-CTB is sent from the previous
   to the next access router in the Context Data message.

   Receiving the context data message with the M-CTB, the next access router
   provides it to the MLDv2 protocol for updating the multicast aggregated
   context and establishement of an individual node MLDv2 context.
   MLDv2 supplies the information from the M-CTB to the multicast routing
   protocol to build the routing context for the multicast addresses.

   This document focusses mainly on the fast multicast and the above
   predictive scenario, when the context transfer is activated at the
   previous access router.

   Further strategies for proactive context transfer could be based on
   sending a context activitate message to the next access router,
   which uses a CTP's Request message to obtain the context for the
   particular mobile node's multicast groups from the previous access

   Due additional message exchange, this kind of proactive context
   transfer is not efficient for Fast Mobile Multicast.

Miloucheva            Expires December 10, 2005                    [Page 5]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

   Reactive scenarios are also slow for fast multicast and include
   additional overhead.
   In these scenarios, the mobile node sends context transfer activation
   to the next access router after the handover [6].
   To optimise context transfer of multicast services, this document
   studies in section 3.3. further strategies for context activation
   based on MIPv6 and its enhancements for Fast Handovers and
   Candidate Access Router Discovery.

3.2. Multicast context transfer block

   The multicast context transfer block (M-CTB) includes the information
   required to re-establish the multicast listening and routing context
   for the moving mobile node at the next access router.
   The multicast context transfer block is designed considering MLDv2
   multicast address records [1]. It has the following structure:

       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
       | NmbRec|       Access Point ID  (M_AP)                       |
       | < ...... Multicast address records ........
      Figure 2: Multicast Context Transfer Block

   M-CTB includes following information:

        o NmbMrec - Number of following multicast address records for
          the access point ID
        o M_AP  (48 Bit)û Access Point Identifier specifying the
          IEEE MAC address of layer 2 device at the next access router
          using which the mobile node will listen to the group.
        o List of multicast address records.

   The M-CTB is included in the Context Data Block of the CTP protocol [6]
   as it is shown in figure 3:

       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
      |   Feature Profile Type (FTP)  |  Length       |P|  Reserved   |
      |                    Presence Vector (if P = 1)                 |
      ~               Multicast Context Transfer Block   (M-CTB)      ~

      Figure 3: Integration of M-CTB in CTP message

Miloucheva            Expires December 10, 2005                    [Page 6]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

   Considering the CTP specification [6], the fields in figure 3 are

        o FPT -  Identifies the type given for the Multicast Context
          Transfer Block (M-CTB). The value is defined by IANA.

        o Length (8-bit unsigned integer) -  Message length in units of
          8 octet words.

        o 'P' bit     0 = No presence vector
                      1 = Presence vector present.

        o Reserved  - Reserved for future use.

        o M-CTB     - M-CTB as defined in this section with length defined
                      by the Length Field. If the data is not 64-bit
                      aligned, the data field is padded with zeros.

   The M-CTB consists of number of multicast address records describing the
   multicast listening state of the mobile node before moving the previous
   access network.
   Each multicast address record has the following structure:

    |  NmbS |F-Type |
    *                       Multicast Address                       *
    *                       Source Address [1]                      *
    |                                                               |
    *                       Source Address [2]                      *
    .                               .                               .
    *                       Source Address [N]                      *

   Figure 4: Multicast address record

   The multicast address record is similar to the address record used
   in the MLDv2 report messages [1]. It includes filter options (F-Types)
   for  source addresses and allows on this way to support SSM [25].

   The Multicast record is defined by following descriptions:

        o NmbS (4 bit unsigned integer) - Number of source addresses
          specified for the multicast group. If the number is 0, then the
          following FilterType is not checked.

        o F-Type (4 bit unsigned integer) - specifies the filter type of
          the source addresses specifed for the multicast grpup.

Miloucheva            Expires December 10, 2005                    [Page 7]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

          Value  Name and Meaning
          -----  ----------------
          1      MODE_IS_INCLUDE - defined in [1].
                 Indicates that the interface has a filter mode of INCLUDE
                 for the specified multicast address and source lists.

          2      MODE_IS_EXCLUDE - defined in [1], Indicates that the
                 interface has a filter mode of EXCLUDE for the specified
                 multicast address and source lists.

        o M_ADR (128 bit)û L3 (IPv6) multicast group address, to which the
          mobile node will listen at the link attached to M_AP.
          Multicast addresses for IPv6 architecture are defined in [20].

        o SourceList û List of IPv6 source addresses (128 bit) to listen
          on the multicast group.
          The addresses are used as information for the multicast routing
          protocol (PIM-SM) to perform source specific multicast and pruning.

3.3. Optimised multicast context transfer

   The section describes optimised multicast context transfer
   based on Fast Handovers MIPv6 environment and  optimal next router
   selection using the CARD protocol is described.

3.3.1 Multicast context transfer for IPv6 Fast Handovers

   IPv6 Fast Handovers has been proposed [16] to minimize the interruption
   in services experienced by a Mobile IPv6 node as it changes its point of
   attachment to the Internet.

   IPv6 Fast Handovers begins when a MN sends RtSolPr to its current
   access router to resolve one or more Access Point Identifiers (AP-IDs)
   to subnet-specific information. In response, the access router sends
   a PrRtAdv message, which contains one or more [AP-ID, AR-Info] tuples.

   With the AR-Info information included in the PrRTAdv
   message, the mobile node formulates a prospective next Care-of address
   establishing and sends Fast Binding Updates.
   IPv6 Fast Handovers protocol integrates predictive and reactive handover
   strategies for mobile node movement using FBUs.

   The multicast context transfer could be triggered by reception of the
   FBU Messages either at the previous or at the next access router:

   -  In the case of predictive handover, the FBU is sent to the previous
      access router and triggers the context transfer activation.

   -  Using the reactive handover, the FBU message is sent to the next AR.

Miloucheva            Expires December 10, 2005                    [Page 8]

INTERNET-DRAFT       Multicast context transfer in MIPv6          June 2005

      It triggers a request for context transfer sent from the next access
      router to the previous.
      As result of this, the previous access router answers with the context
      transfer data.

   Predictive multicast context transfer triggered by FBU in Fast Handovers
   MIPv6 is given in figure 5;

    Mobile Node                  Prev-AR                       Next-AR
    |                                   |            RtAdv          |
    |                                   |          <----------------|
    |RtSolPr                            |                           |
    |---------------->                  |                           |
    |                                   |                           |
    |                   PrRtAdv         |                           |
    |                  <----------------|                           |
    |                                   |                           |
    |FBU                                |                           |
    |----------------->                 |                           |
    |                     M-CTB trigger*| Context Transfer(M-CTB)   |
    |                                   | ----------------------->  |
    |                                   |                           |

     Figure 5: Predictive multicast context transfer in Fast Handovers MIPv6

   Because the multicast context transfer is based on triggering using the
   FBU message, it is similar to the proposal in [8]. The difference is that
   [8] includes in the FBU the mobile node's  multicast context data.

3.3.2 Multicast support with CARD protocol

   The Candidate Access Router Discovery (CARD) protocol was designed
   to support the acquisition of information about the possible next ARs
   that are candidates for the mobile node's handover [7].
   CARD protocol is used in EU project DAIDALOS [14] together
   with the Context Transfer protocol [6] and IPv6 Fast Handovers
   [16] for efficient handover aimed at optimization of service
   re-establishment in case of MIPv6 node handover.

   There are different issues for candidate access router discovery [13].
   CARD could be used for the selection of a next router, which has
   already established multicast listening and routing states for the
   multicast groups, required by the mobile node.
   For this purpose the multicast context as defined in section 3.2.
   should be included as sub-option in the CARD Reply Signalling message
   exchanged between access routers and mobile nodes.

   The steps in usage of CARD for selection of optimal multicast router
   are shown in figure 6:

Miloucheva            Expires December 10, 2005                    [Page 9]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

   Mobile Node                  Prev-AR                            Next-AR
   |                                  |                                 |
   |                                  |AR-AR CARD Request               |
   |                                  |------------------>              |
   |                                  |                                 |
   |                                  |          AR-AR CARD Reply(M-CTB)|
   |                                  |             <------------------ |
   |MN-AR CARD Request                |                                 |
   |------------------ >              |                                 |
   |                                  |                                 |
   |           MN-AR CARD Reply(M-CTB)|                                 |
   |          <-----------------------|                                 |
   |*selection of optimal CAR         |                                 |
   |*based on multicast context       |                                 |
   |                                  |                                 |

      Figure 6: Selection of optimal multicast router based on CARD

4.   Operational requirements for IPv6 Multicast protocols

4.1 Requirements for MLDv2

4.1.1. MLDv2 context extension

   The following requirements concerns the operation and context maintained
   at the "router" part of the MLDv2 protocol.
   The "host" part of MLDv2 and its contexts per socket and interface remain
   the same.

   For multicast context transfer, MLDv2 must keep per node (host)
   multicast group listener status on the interface.

   Currently, the MLDv2 is designed to support the ASM [21] and SSM [19]
   The MLDv2 context at the multicast router keeps the aggregated
   node information for multicast interfaces based on which the multicast
   router knows that "at least one" node multicast on the attached link
   is listening to packets for a particular multicast address.

   Considerations for the MLDv2 routers to track per-host multicast listener
   status on an interface are discussed in Appendix A.2 of the MLDv2
   To provide Multicast Context Transfer in MIPv6, it is a requirement for
   MLDv2 to build a multicast listener context per host (node) at the
   multicast access router in order to supply information for the building
   of the Multicast Control block.

   Figure 7 shows an entry of the context per mobile node extending the
   current aggregated MLDv2 context per given interface.

Miloucheva            Expires December 10, 2005                   [Page 10]

INTERNET-DRAFT       Multicast context transfer in MIPv6          June 2005

    |       |
    |       |
    |                                                               |
    *                     Mobile Node Address                       *
    |                                                               |
    |                                                               |
    *      MRef         |...........................................*
    |                                                               |

   Figure 7: MLDv2 context per node for a given link at the access router

   The Multicast record is defined by following descriptions:

        o Nb-MRef (4 bit unsigned integer) - Number of references of the
          mobile node to entries in the aggregated MLDv2 context at AR.
          Each entry specifies a multicast group to which the mobile node
          is listening.
        o M-Adr (128 bit unsigned integer) - specifies the IPv6 address
          of the mobile node listening to the multicast groups and interfaces
          specified by MRef.
        o MRef  - specifies the memory address of the entry in the
          aggregated MLDv2 context.

   The proposed structures for extension of MLDv2 does not change the current
   aggregated context per interface and allow interoperation with existing
   MLDv2 implementations.

4.1.2 Operational considerations

   Based on the multicast listener context per node, MLDv2 builds the M-CTB,
   as result of context transfer activation or triggering.
   The M-CTB is supplied by MLDv2 to the Context transfer Protocol entity at
   the  previous access router. It builds a valid context transfer data
   message and sends it to the next router.

   Receiving the CTP message with the M-CTB, the CTP entity, the next AR
   supplies the M-CTB to the MLDv2 for further processing.
   The processing of the M-CTB requires that MLDv2 changes the multicast
   context data at the next AR and invokes PIM-SM for building of multicast
   routing updates.

4.2 Requirements for multicast routing (PIM-SM)

   Using the multicast context block, MLDv2 provides information to the

Miloucheva            Expires December 10, 2005                   [Page 11]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

   particular multicast routing protocol to build the routes and establish
   the routing context to the multicast addresses as required by the node.
   If routes already exist, nothing is done. Otherwise, the actions depend
   on the used multicast routing protocol.

   In case of PIM-SM, there are different tasks for routing context
   establishment considering the M-CTB information.

   - In case that in M-CTB a multicast group address (G) without sources is
   specified, the PIM-SM routing is required to perform (*, G) Join actions.
   This means a join to a route for all sources of the group.

   - In case that M-CTB includes the option "INCLUDE" for a particular group
   address (G) and the source list (S), PIM-SM translates it in (S,G) join
   and uses the specification [4] to provide source-specific join.

   - When M-CTB includes an multicast address record with the option "EXCLUDE"
   for the particular multicast group address (G) and source list (S),
   the (S,G,rpt) source-specific pruning actions should be performed as
   specified in [4].

5. Comparison with other IPv6 mobile multicast protocols

   Mobility for IPv6 defines the multicast services for mobile nodes [5].
   The proposed solution is slow, because it is based on the forwarding of
   the multicast packets by the Home Agents via the tunnel to the mobile

   Multicast solutions extending mobile IPv6 multicast [5] are proposed for
   Fast Handover [16] and Hierarchical Mobile IPv6 environments [18].

   The multicast protocol for Fast Handover MIPv6 [8] is based on integration
   of multicast flag in PrRtAdv message and multicast option in the Fast
   Binding Update. This option includes information describing the active
   multicast groups of the mobile node, for which the new access router
   should establish multicast listening and routing context.

   The fast mobile multicast in the framework of Hierarchical Mobile IPv6
   (H-MIPv6) and MIPv6 mechanisms is proposed in [9].
   The multicast distribution is based on Mobility Anchor Points defined
   for the H-MIPv6 architectures. In M-HMIPv6, a mobile multicast node uses
   its local MAP as anchor point for multicast communication.
   All multicast traffic is directed through this MAP using the Regional
   Care-of Address.
   Traffic forwarding between MN and its MAP is done using a bi-directional
   tunnel. If a MN changes location within its MAP domain, it only
   registers its new Care-of Address with the MAP [D-HMIPv6], which does
   not affect multicast routing trees.

Miloucheva            Expires December 10, 2005                   [Page 12]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

   When entering a new MAP domain, a MN will be eager to sustain multicast
   connectivity via its previously established MAP.
   Multicast handover procedures will occur, only if the MN changes into a
   new M-HMIPv6 enabled MAP domain, and will then shift multicast traffic
   from the previous to the current MAP.
   In H-MIPv6,  MLDv2 reports are extended with attendance code field to
   support multicast routing optimisation. The two approaches are based on
   extensions of specific protocols for seamless mobile handover in IPv6.

   Compared with these approaches, multicast context transfer as proposed
   in the current Draft could be integrated in different mobile IP
   architectures as it is shown in section 3.1 and 3.3.
   Because of the individual contexts at the ARs, a scalability problem
   dependent on the number of receiving mobile nodes arises.
   In case of great number of mobile nodes using a particular access
   router for mobile multicast, performance degradation is possible, which
   should be considered in the design and implementation.

6. IANA considerations

   IANA should record a value for identification of multicast context
   transfer block (M-CTB).

7. Further work

   This draft specifies the multicast receiver mobility based on context
   transfer. It is intended for mobile nodes listening to multicast groups
   based on ASM model or subscribed to multicast channels using SSM.
   Multicast source mobility in the context of SSM needs further work and


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

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

  [3]   D.  Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley,
        V. Jacobson, C. Liu, P. Sharma, L. Wei,"Protocol Independent
        Multicast-Sparse Mode (PIM-SM): Protocol Specification",
        RFC 2362, Experimental, June, 1998

  [4]   B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent
        Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)",
        draft-ietf-pim-sm-v2-new-10.txt, July 2004, Work in Progress

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

Miloucheva            Expires December 10, 2005                   [Page 13]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

  [6]   J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, Context Transfer
         Protocol, draft-ietf-seamoby-ctp-11.txt, August, 2004

  [7]   M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim, Candidate Access
        Router Discovery, IETF Seamoby Working Group, Internet Draft,
        draft-ietf-seamoby-card-protocol-08.txt, September 2004

  [8]   K.Suh, D-H. Kwon, Y-J. Suh, Y. Park, Fast Multicast Protocol
        for Mobile Ipv6 in the fast handovers environment,
        draft-suh-mipshop-fmcast-mip6-00.txt, January 2004, Work in Progress

  [9]   T.C. Schmidt, M. Waehlisch. Seamless Multicast Handover in a
        Hierarchical Mobile Ipv6 Environemnt (M-HMIPv6),
        draft-schmidt-waehlisch-mhmipv6-03.txt, April 2005, Work in Progress

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

  [11]  J. Manner, M. Kojo, Ed., "Mobility Related Terminology", Network
        Working Group, RFC 3753, Informational, June 2004

  [12]  S. Bradner, V. Paxson, "IANA Allocation Guidelines For Values In the
        Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.

  [13]  J. Kempf et al., "Problem Description: Reasons For Performing Context
        Transfers Between Nodes in an IP Access Network", RFC 3374, May 2001.

  [14]  Designing Advanced Interfaces for the Delivery and Administration
        of Location independent Optimised personal Services, DAIDALOS
        EU IST project, www.ist-daidalos.org

  [15]  I. Miloucheva, O. Menzel, Support of mobile nodes with unidirectional
        links in MIPv6, Internet Draft, June 2005, Work in Progress

  [16]  R. Koodli (ed.), Fast Handovers for Mobile Ipv6, November 2004,
        Internet Draft, Work in Progress

  [17]  M.Vieth, O.Menzel, I.Miloucheva, K.Jonas, J.Plßcido,  H.Santos,
        E. Guainella, Learning for efficient handover of QoS based mobile
        multicast services CITSA Conference, July 2005

  [18]  H.Soliman, C. Catelluccia, K.Malki, L. Bellier, Hierarchical Mobile
        IPv6 mobility management(HMIPv6), Internet Draft, December 2004

  [19]  [D-HC 04a] Holbrook, H. and B. Cain, "Source-Specific Multicast",
        Interet Draft, September 2004, Work in Progress.

  [20]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture, RFC 3513, April 2003.

Miloucheva            Expires December 10, 2005                   [Page 14]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

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

  [22]  D. Thaler, B. Fenner, and B. Quinn, Socket Interface Extensions
        for Multicast Source Filters. RFC 3678, January 2004.

  [23]  H. Holbrook and B. Cain, "IGMPv3/MLDv2 for SSM", Internet Draft,
        Work in Progress, June 2004.

  [24]  S. Bhattacharyya,  An Overview for Source-Specific Multicast (SSM),
        RFC 3569, July 2003

Author's Addresses

Ilka Miloucheva
Fraunhofer Institute
SATCOM FOKUS,Schloss Birlinghoven       Phone: +49-2241-14-3471
53757 Sankt Augustin, Germany           email: ilka@fokus.fraunhofer.de

Karl Jonas
Fraunhofer Institute
SATCOM FOKUS,Schloss Birlinghoven       Phone: +49-2241-14-1599
53754 Sankt Augustin, Germany           Email: karl.jonas@ieee.org

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

   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

Miloucheva            Expires December 10, 2005                   [Page 15]

INTERNET-DRAFT       Multicast context transfer in IPv6           June 2005

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Miloucheva            Expires December 10, 2005                 [Page 16]