I. Miloucheva, Internet Draft K. Jonas Expires: December 10, 2005 SATCOM June 8, 2005 Multicast Context Transfer in mobile IPv6 draft-miloucheva-mldv2-mipv6-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. 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 December 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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 specified. 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 [15]. 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 specified. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 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 router. 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 defined: 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] models. 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 specification. 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 +-+-+-+-+ | | |Nb-MRef| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * 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 nodes. 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 specification. References [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 http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Miloucheva Expires December 10, 2005 [Page 16]