IP Mobility Optimizations WG H. Santos Internet-Draft Instituto de Telecomunicacoes Expires: August 31, 2006 R. Aguiar Universidade de Aveiro I. Miloucheva K. Jonas Fraunhofer Institute SATCOM February 27, 2006 Context Transfer of Mobile IPv6 Multicast Listeners draft-santos-mobopts-mcast-ctx-transfer-00 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 August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a framework for the Context Transfer Protocol to provide the transfer of multicast listener context information between Access Router to optimize the re-activation of the multicast flows required by the terminals with minimal service disruption. Santos, et al. Expires August 31, 2006 [Page 1] Internet-Draft Multicast Context Transfer February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions used in this document . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multicast Context transfer . . . . . . . . . . . . . . . . . . 4 2.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Predictive network controlled multicast context transfer . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2 Reactive network controlled multicast context transfer . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Multicast context transfer block . . . . . . . . . . . . . 6 2.2.1 Optional Active source list . . . . . . . . . . . . . 9 2.3 Optimized multicast context transfer . . . . . . . . . . . 10 2.3.1 Multicast context transfer for IPv6 Fast Handovers . . 10 2.3.2 Multicast support with CARD protocol . . . . . . . . . 11 3. Operational requirements for MLDv2 . . . . . . . . . . . . . . 12 3.1 MLDv2 context and operation extension . . . . . . . . . . 12 3.2 Operational considerations . . . . . . . . . . . . . . . . 13 3.2.1 At the previous Access Router . . . . . . . . . . . . 13 3.2.2 At the new Access Router . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Santos, et al. Expires August 31, 2006 [Page 2] Internet-Draft Multicast Context Transfer February 2006 1. Introduction Context transfers are proposed for mobile nodes in order to quickly re-establish their services when the nodes move and change access networks [14]. The Context Transfer protocol (CXTP) [1], designed by the IETF Seamoby WG as an Experimental protocol for usage in Mobile IPv4 and MIPv6 environments, aims to provide general mechanisms for the exchange of context data for moving mobile nodes between access routers. In the Appendix B of the CXTP specification [1] an example for multicast listener context transfer in IPv6 considering MLD [2] is given. In this example, for each active multicast group at the access router, a MLD context is established. As the access routers maintain an aggregate MLD context information, they are not able to distinguish contexts of individual nodes. As a consequence, all established contexts for subscribed multicast group addresses in the link where the mobile node was attached to at the previous access router will be transferred to the next router when the mobile node moves to a new network. This causes network and processing overhead due to the creation of multicast contexts and distribution trees in the next access routers for multicast groups which are not required by their attached mobile nodes. The focus of this document is the context transfer of the Multicast Listener Discovery Protocol (MLDv2) protocol states in a mobile IPv6 (MIPv6) environment. It is aimed to support seamless handover for mobile receivers using MLDv2 for either the Any Source [3] or Source Specific Multicast [15] models. The multicast context transfer operations and data structures required for MLDv2 service re-establishment in Mobile IPv6 scenarios are described. Facilities for optimized multicast context transfer based on the Fast Handovers for MIPv6 [4] and Candidate Access Router Discovery (CARD) protocol [5] are overviewed. Finally, the required extensions to the MLDv2 router implementations are addressed. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6] . 1.2 Terminology The Internet Protocol (IP) multicast service model for any source Santos, et al. Expires August 31, 2006 [Page 3] Internet-Draft Multicast Context Transfer February 2006 multicast (ASM) is overviewed in RFC 1112 [3]. Source specific multicast (SSM) provides network-layer support for one-to-many delivery only and is described in [16], [15], [17], [18]. Multicast Listener Discovery Version (MLDv2) for IPv6 is defined in [7] as extension of MLD [2]. PIM-SM is specified in [8], [9]. The focus of [19] is an architecture for fast handover with integrated access control based on [4]. Terminology used in this document follows the conventions established in the documents above. In particular, the following acronyms are often referred to: AR Access Router pAR Previous Access Router nAR Next Access Router MN Mobile Node CXTP Context Transfer Protocol M-CTB Multicast Context Transfer Block ASM Any Source Multicast SSM Source Specific Multicast FBU Fast Binding Update CTD Context Transfer Data CTDR Context Transfer Data Reply CTAR Context Transfer Activate Request 2. Multicast Context transfer 2.1 Protocol Overview Access routers in IPv6 use the Multicast Listener Discovery Protocol version 2 (MLDv2) [7] (a more robust version of the original MLD protocol [2]) which also supports Source Specific Multicast [16], [17] to signal the multicast routers with their multicast interest. The active multicast routing protocols will then use the local interest information provided by MLDv2 to build the multicast distribution trees required to serve the listeners in a particular interface. The multicast context transfer is used during a mobile node's handover in order to provide the next access router with the mobile node's listening state so the various routing contexts may be established in behalf of the mobile node for the multicast groups required by it's active multicast services. In the scenarios described in this document, the transfer of context information is supported by the Context Transfer Protocol (CXTP) [1]. According to CXTP, there are different scenarios for the triggering of a context transfer: Santos, et al. Expires August 31, 2006 [Page 4] Internet-Draft Multicast Context Transfer February 2006 - Network controlled initiated by previous or next access router - Mobile node controlled triggered by the mobile node To support optimised handovers, the context transfer could be used in interaction with Fast Handovers for MIPv6 [4] and Candidate Access Router Discovery [5] protocols as will be described in later sections. 2.1.1 Predictive network controlled multicast context transfer In the predictive scenario for multicast context transfer (see Figure 1), the previous access router initiates the context transfer. The multicast context transfer block (M-CTB) for the multicast services of the mobile node is built in the pAR with input from the MLDv2 router entity and transferred to the nAR. The M-CTB includes the multicast addresses required for the multicast services being used by the moving mobile node. In predictive scenarios, the pAR sends the keying material, the M-CTB and other information necessary to calculate the Authorization Token. After receiving the context data message with the M-CTB, the next access router dispatches it to the MLDv2 router entity in order to establish an individual node context and to update the aggregate state. A change in the aggregated state will then trigger the active multicast routing protocol to build the distribution trees for each of the multicast groups. +---------------+ +--------------+ | previous AR | (1) CTD | next AR | |---------------| with M-CTB |--------------| | MLDv2 context | ------------> | updated | | (per node and | | MLDv2 | (2) CTAR | aggregate) | <------------ | context |<-----+ +---------------+ (3) CTDR +--------------+ | || || | || multicast || multicast | || data || data | \/ \/ | +-------------------+ +-------------------+ | | Mobile | MLDv2 | handover | Mobile | MLDv2 |-+ | Node | state | ----------> | Node | state | +-------------------+ +-------------------+ Figure 1: Predictive network controlled multicast context transfer When the mobile node performs the handover, it sends a message CTAR to activate the context transfer. The CTAR message is sent either to pAR or nAR, depending on the router, to which the mobile node is Santos, et al. Expires August 31, 2006 [Page 5] Internet-Draft Multicast Context Transfer February 2006 connected. If CTAR is sent to pAR, the MN includes the nAR's IP address; otherwise, if the message is sent to nAR, the pAR address is sent. The CTDR message is sent by nAR to pAR as response of CTD, when CTD requires response indicating success or failure of context transfer. 2.1.2 Reactive network controlled multicast context transfer The reactive scenario differentiates from the predictive in the fact that the next access router triggers the multicast context transfer sending the CT-Req message to the pAR. After receiving the CT-Req message, the pAR sends a CTD message with M-CTB including the context data for the active mobile node's MLDv2 states. The following signalling messages are performed as it is described in Section 2.1.1. The reactive network controlled multicast context transfer is shown in Figure 2. +---------------+ (1) CT-Req +--------------+ | previous AR | <------------ | next AR | |---------------| (2) CTD |--------------| | MLDv2 context | with M-CTB | updated | | (per node and | ------------> | MLDv2 | (3) CTAR | aggregate) | <------------ | context |<-----+ +---------------+ (4) CTDR +--------------+ | || || | || multicast || multicast | || data || data | \/ \/ | +-------------------+ +-------------------+ | | Mobile | MLDv2 | handover | Mobile | MLDv2 |-+ | Node | state | ----------> | Node | state | +-------------------+ +-------------------+ Figure 2: Reactive network controlled multicast context transfer 2.2 Multicast context transfer block The multicast context transfer block (M-CTB) includes the feature data, i.e. the information required to re-establish the multicast listening and routing context for the moving mobile node at the next access router. It consists of a list of Multicast Group Records, one for each group the mobile node is interested in. Santos, et al. Expires August 31, 2006 [Page 6] Internet-Draft Multicast Context Transfer February 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Record 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Record 2 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Record N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Multicast Context Transfer Block Each Multicast Group Record describes the mobile node's multicast filter for the specified multicast group and additional optional information that may be of interest to the next Access Router (access and authorization group data, optimization hints, etc). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Count | Option Length |F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Group | | Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source | | Address 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source | | Address N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | OptLen | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Multicast Group Record Santos, et al. Expires August 31, 2006 [Page 7] Internet-Draft Multicast Context Transfer February 2006 Each Multicast Group Record contains the following fields: o Source Count (8 bit unsigned integer) - Number of source addresses included in the Multicast Group Record. o Option Length (8 bit unsigned integer) - Length in 8 octet units of the sum of all option fields included in this record. If no options are included this field MUST be zero. o F field (1 bit) - Specifies the filter mode, with the following two possibilities * EXCLUDE (0) - Indicates that the filter mode is EXCLUDE for the specified multicast group and source list. * INCLUDE (1) - Indicates that the filter mode is INCLUDE for the specified multicast group and source list. o Reserved (15 bits) - This field is reserved for future usage. o Multicast Group Address - Address of the multicast group the mobile node is interested in. IPv6 multicast addresses are defined in [10]. o SourceList (from 0 to N) - List of IPv6 source addresses that together with the filter mode constitute the mobile node's multicast filter for the specified group. o Option Type (8 bit) - Specifies the option's identifier. If the encoded identifier has a value of 128 or greater, the processing of the option is mandatory. In this case, if the next Access Router doesn't know the option identifier value, the complete Multicast Group Record MUST not be processed. The following options are defined in this document: * PAD1 (0) and PADN (1) - IPv6 padding options as defined in [11] * Active source list (2) - not mandatory, specified in Section 2.2.1 o OptLen (8 bit unsigned integer) - This field encodes the length of the option in 8 octet units excluding the first 8 octets of the option. All options have a minimum size of 8 octets. The M-CTB is included in the Context Data Block of the CTP protocol [1] as it is shown in Figure 5: 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 (FPT) | Length |0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Context Transfer Block (M-CTB) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Integration of M-CTB in CTP message Considering the CXTP specification [1], the fields in Figure 5 are defined: Santos, et al. Expires August 31, 2006 [Page 8] Internet-Draft Multicast Context Transfer February 2006 o FPT - The IANA allocated Feature Profile Type for the Multicast Context Transfer Block (M-CTB). o Length (8-bit unsigned integer) - The length of the Multicast Context Transfer Block in 8 octet words. o 'P' bit is always zero. o Reserved - Reserved for future use. o M-CTB - M-CTB as defined in this section. If the data is not aligned to 8 octets, the field is padded with zeros. 2.2.1 Optional Active source list For the transfer of Any Source Multicast groups, if the next Access Router has no previous state for the group being transfered, it would need to rediscover the active sources for the group which introduces significant delay in the re-establishment of the mobile node's multicast sessions. To optimize this scenario, the previous Access Router may include the known active sources for the group in the Active source list option. The next Access Router MAY use this information to short circuit the source discovery mechanism and quickly re-establish the multicast distribution tree. It is recommended that, even if this is made, the Access Router performs the source discovery mechanism in background, due to multicast route optimization. The source list SHOULD be ignored either if required by configuration or if the Context Transfer Block originates from a distinct administrative domain. Refer to Section 4 for more information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option = 2 | Len = Count/2 | zero (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source | | Address 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Santos, et al. Expires August 31, 2006 [Page 9] Internet-Draft Multicast Context Transfer February 2006 Figure 6: Active source list Multicast Group Record Option The Active source list option contains the following details: o Mandatory flag is zero (0) o Option identifier is one (1) o Option Length will be the number of sources (N) times 4 (16 octets per address) plus the option header (1 octet). o Reserved (16 bits) - Reserved for future use o Source Addresses - The active source list 2.3 Optimized multicast context transfer This section describes optimized multicast context transfer based on the Fast Handovers MIPv6 environment and optimal next router selection using the CARD protocol [5]. 2.3.1 Multicast context transfer for IPv6 Fast Handovers IPv6 Fast Handovers [4] have been proposed to minimize the interruption in services experienced by a Mobile IPv6 node as it changes its point of attachment to the Internet. An IPv6 Fast Handover begins when a mobile node sends a 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 and sends Fast Binding Updates (FBU). The 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: o In the case of predictive handover, the Fast Binding Update (FBU) is sent to the previous access router which triggers the context transfer activation. o Using the reactive handover, the FBU message is sent to the next AR. It triggers a request for context transfer sent from the next access router to the previous. As a result, the previous access router responds with the context transfer data. Predictive multicast context transfer triggered by FBU in Fast Handovers MIPv6 is described in Figure 7: Santos, et al. Expires August 31, 2006 [Page 10] Internet-Draft Multicast Context Transfer February 2006 Mobile Node Prev-AR New-AR | | RtAdv | | |<------------------| | RtSolPr | | |------------------->| | | | | | PrRtAdv | | |<-------------------| | | | | | FBU | | |------------------->| | | M-CTB trigger | CT Data (M-CTB) | | |------------------>| | | | Figure 7: Predictive multicast context transfer in Fast Handovers MIPv6 Because the multicast context transfer is based on triggering using a FBU message, it is similar to the proposal in [20]. The difference with this proposal is that in [20] the FBU includes the mobile node's multicast context data. 2.3.2 Multicast support with CARD protocol The Candidate Access Router Discovery (CARD) [5] protocol was designed to support the retrieval of information about the candidate next access routers for the mobile node's handover. In the context of this document, CARD could be used for the selection of an optimal next access router based on whether a candidate access router has already established multicast listening and routing states for the multicast groups required by the mobile node. To support this decision the Multicast Context Transfer Block (M-CTB) defined in Section 2.2 COULD be included as a sub-option in the CARD Reply signalling message exchanged between access routers and mobile nodes. A description of the signalling used on the usage of CARD for the selection of the optimal multicast router is shown in Figure 8. Santos, et al. Expires August 31, 2006 [Page 11] Internet-Draft Multicast Context Transfer February 2006 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 mcast ctx | | | | | Figure 8: Selection of optimal multicast router based on CARD 3. Operational requirements for MLDv2 The following requirements concern the operation and states maintained by the MLDv2 router. MLDv2 host implementations do not require any changes to be compliant with this document. 3.1 MLDv2 context and operation extension The default MLDv2 operations specify an aggregate multicast filter kept by interface, which is built from each of the listener's interest. If for a particular group an interface's multicast filter is not INCLUDE {}, there is at least one listener attached to that interface interested in that group. In order to support the context transfer of the listener's multicast filter, the MLDv2 router MUST keep each node's individual interest per interface. As most Access Routers are designed to support up to a few dozen terminals, keeping an individual state for each terminal should not prove to be a scalability problem. As stated in [7], multicast routers that implement the MLDv2 protocol keep state per multicast address per attached link. This multicast address state consists of a filter mode, a list of sources and various timers. (IPv6 multicast address, Filter Timer, (source records)) Where each source record is of the form: Santos, et al. Expires August 31, 2006 [Page 12] Internet-Draft Multicast Context Transfer February 2006 (IPv6 source address, source timer) In order to implement the context transfer of multicast listening information, besides the above aggregate state, the MLDv2 router must also keep a record per multicast group address that includes each of the node's information, including Filter Timer and source list. (IPv6 multicast address, Filter Timer, (source records), (node records)) Where each node record is of the form: (IPv6 listener address, Filter Timer, (source records)) As the Filter Timer and source addresses are handled per listening node, an implementation may opt not to implement both the Filter Timer and Source timers in the aggregate state, relaying on the individual state information only. The proposed extension to MLDv2's structures does not change the current aggregated context per interface and allow inter-operation with existing MLDv2 implementations. 3.2 Operational considerations The following sections discuss the operational considerations at both the old and new access routers. 3.2.1 At the previous Access Router After the transfer of a multicast context to a new Access Router, the old multicast context should be removed after a configured time value. This value should be low enough so the old multicast tree may be pruned within a reasonable time in order to minimize unnecessary resource usage. On the other hand, it should be high enough to, as an optimization, include potential returns of the mobile node to the previous access network without the Access Router having to re-build all the required states, including the required multicast distribution trees. The recommended time value is 30 seconds. After the removal of the multicast context, the aggregate multicast filter should be rebuilt from the remaining individual contexts. Depending on the MLDv2 router implementation an internal CHANGE_TO_INCLUDE message with an empty source list could also be triggered to simulate the leaving terminal. Santos, et al. Expires August 31, 2006 [Page 13] Internet-Draft Multicast Context Transfer February 2006 3.2.2 At the new Access Router After receiving a Context Transfer Data (CTD) message with a M-CTB, the CXTP entity at the next access router supplies the included information to the MLDv2 router which will trigger the update of the aggregate state for the included groups and consequent building of multicast distribution trees by the active multicast routing protocol. When handling the aggregate context transitions, a filter mode of EXCLUDE in a Multicast Group Record should trigger a IS_EXCLUDE MLDv2 router state-machine transition while a INCLUDE mode should trigger a IS_INCLUDE transition. Both transactions provide the required changes to the state-machine. The MLDv2 router must also create new multicast contexts for the moving mobile node as if the signalling was receiving explicitly. These new contexts should be created with a lifetime of a fraction of [Multicast Address Listening Interval]. Multicast Address specific Queries for each Multicast group included in the M-CTB should be triggered as per [7]. This will enable the created contexts to be quickly refreshed if the multicast terminal stayed at the new access network. If the new access network was only a transactional network or if the mobile node returned to the old access network, the short lifetime will enable the context to be shortly timed out. By allowing the context to live for a period of time we guarantee that the mobile node will be continually served even if frequently moving in the edge of two or more access networks. 4. Security Considerations Generic security relevant aspects related to Context Transfers are discussed in RFC4067 [1] Security Considerations section. The Active source list option may include source addresses which aren't accessible or have been compromised in the Access network of the next Access Router. This option SHOULD be ignored when transferred between administrative domains. Access Routers are supposed to be non-compromised in this document, otherwise denial-of- service attacks could be easily implemented. 5. IANA Considerations A Feature Profile Type (FPT) must be allocated by the IANA for the Multicast Context Transfer Block (M-CTB). The allocation of Multicast Group Record Option Fields must be Santos, et al. Expires August 31, 2006 [Page 14] Internet-Draft Multicast Context Transfer February 2006 managed by the IANA. 6. Acknowledgements This draft is being partially implemented in the scope of project IST-Daidalos. Comments and contributions from project partners are deeply acknowledged. 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. 8. References 8.1 Normative References [1] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [2] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [5] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [8] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [9] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Santos, et al. Expires August 31, 2006 [Page 15] Internet-Draft Multicast Context Transfer February 2006 "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-11 (work in progress), October 2004. [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [12] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. 8.2 Informative References [14] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. [15] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [16] Cain, B. and H. Holbrook, "Source-Specific Multicast for IP", draft-holbrook-ssm-arch-03 (work in progress), November 2001. [17] Holbrook, H., Cain, B., and B. Haberman, "Using IGMPv3 and MLDv2 For Source-Specific Multicast", draft-holbrook-idmr-igmpv3-ssm-08 (work in progress), October 2004. [18] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004. [19] Melia, T., "Network initiated handover in fast mobile IPv6", draft-melia-mobopts-niho-fmip-01 (work in progress), July 2005. [20] Suh, K., "Fast Multicast Protocol for Mobile IPv6", draft-suh-mipshop-fmcast-mip6-00 (work in progress), February 2004. [21] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. Santos, et al. Expires August 31, 2006 [Page 16] Internet-Draft Multicast Context Transfer February 2006 [22] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [23] Miloucheva, I. and O. Menzel, "Support of mobile nodes with unidirectional links in MIPv6", draft-miloucheva-udlr-mipv6-00 (work in progress), June 2005. [24] Schmidt, T. and M. Waehlisch, "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", draft-schmidt-waehlisch-mhmipv6-03 (work in progress), April 2005. Authors' Addresses Hugo Santos Instituto de Telecomunicacoes Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: hsantos@av.it.pt Rui L. Aguiar Universidade de Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: ruilaa@det.ua.pt Ilka Miloucheva Fraunhofer Institute SATCOM SATCOM FOKUS, Schloss Birlinghoven Sankt Augustin 53757 Germany Phone: +49-2241-14-3471 Email: ilka@fokus.fraunhofer.de Santos, et al. Expires August 31, 2006 [Page 17] Internet-Draft Multicast Context Transfer February 2006 Karl Jonas Fraunhofer Institute SATCOM SATCOM FOKUS, Schloss Birlinghoven Sankt Augustin 53757 Germany Phone: +49-2241-14-3471 Email: karl.jonas@ieee.org Santos, et al. Expires August 31, 2006 [Page 18] Internet-Draft Multicast Context Transfer February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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. Santos, et al. Expires August 31, 2006 [Page 19]