MULTIMOB Group D. von Hugo Internet-Draft Telekom Innovation Laboratories Intended status: Experimental H. Asaeda Expires: September 6, 2012 Keio University P. Seite France Telecom - Orange March 5, 2012 Context Transfer for Multicast support in Distributed Mobility Management (DMM) draft-vonhugo-multimob-dmm-context-00 Abstract This document describes a context transfer based concept to support overarching IP multicast services applicable to various existing approaches for Distributed Mobility Management. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of von Hugo, et al. Expires September 6, 2012 [Page 1] Internet-Draft Context Transfer for DMM Multicast March 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. Handover Process . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Multicast Context Transfer Data Format . . . . . . . . . . 7 3.2. Multicast Context Transfer with MLD Proxy . . . . . . . . 7 3.3. Multicast Context Transfer with PIM-SM . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 von Hugo, et al. Expires September 6, 2012 [Page 2] Internet-Draft Context Transfer for DMM Multicast March 2012 1. Introduction This document describes an application of various existing approaches for Distributed Mobility Management (DMM) [15] to support overarching IP multicast services with Proxy Mobile IPv6 (PMIPv6) [3] and Client Mobile IPv6 (MIPv6) [2], respectively. Key concept of Distributed Mobility Management (DMM) in a flat network architecture where core entities and functionalities are deployed in a distributed manner assumes a mobile node to use the first access router (AR) it attaches to as principal mobility anchor, i.e. Home Agent (HA) in MIPv6 or Local Mobility Anchor (LMA) in PMIPv6. Current proposals for DMM based Mobility such as MIP-based Distributed Mobility Anchoring (DMA) [16] and [21] as well as PMIP-based solutions for Distributed Mobility Management [17], [20] ... and so forth define new AR capabilities applicable to a flat architecture. Common idea of the various approaches is to distribute functionalities for local attachment of a MN to the network and for dynamically keeping track of a MN and its current sessions, also in case of MN attachment to a different AR, to all Access Routers. These ARs are denoted here by DMM ARs (DARs) which are responsible for hosting (anchoring) newly attached MNs and their started sessions (flows), and for relaying old sessions to the MNs' previous DAR(s), respectively. Some solutions refer to a common data base containing all relevant MN information for retrieval which may be co-located with existing logical entities such as DMM-defined Local Mobility Anchor (LMA) or a new common central Mobility Database (MDB). The MultiMob Base Protocol [12] specifies a mechanism for supporting multicast reception within a PMIPv6 domain using Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") [7]. Several extensions have been proposed to optimize Routing or session continuity during Handover of a MN. While some approaches rely on the LMA anchoring of a MN to speed up the subscription process during handover as proposed in [19] others apply on an extension of Context Transfer Protocol (CXTP) [10] specification directly [11] or via the established fast HO approach using FPMIP/FMIP [14] to support forwarding of multicast group subscription and traffic data between MAGs. Within a DMM-like approach where location (i.e. anchoring) and access functionality can be handled by the same entity a data exchange between the current AR and a prior one to ensure low delay and loss could be achieved without enhancing complexity too much by applying the CTXP modification directly. In case of node mobility during an ongoing multicast reception session the node should be able to continuously receive the multicast data through the new AR just after handover completion without any MLD signaling on the new wireless link. This procedure is multicast context transfer that provides multicast session continuity and avoids extra packet loss and session disruption. Multicast context transfer will be the von Hugo, et al. Expires September 6, 2012 [Page 3] Internet-Draft Context Transfer for DMM Multicast March 2012 required function to support seamless handover, while for its effective procedure, interaction with multicast communication protocols should be taken into account. To synchronize multicast with unicast traffic measures to prevent delay extension due to waiting for multicast information should be established as proposed in [19] The Context Transfer Protocol (CXTP) specification [10] describes the mechanism that allows better support for minimizing service disruption during handover. This document proposes to extend CXTP for forwarding of multicast context transfer in a DMM domain. "Multicast-Context Transfer Data (M-CTD)" message as defined in [11] is applied here for transferring multicast membership states between the previously attached DAR (p-DAR) to a newly attached DAR (n-DAR) within a DMM domain. The context transfer is either started from the n-DAR on its own after attachment of the mobile node or initiated by the p-DAR after being informed by the access network of the planned handover. Existing DMM proposals assume that for data exchange between p-DAR and n-DAR a dedicated tunnel already is in place. Details of the set-up procedure for this tunnel are therefore out of scope of this document. Depending on the scenario of multicast application the real-time delivery of content may be more important than lossless and error- free transmission. Thus to allow for temporary storage or buffering at a previous access router during handover and subsequent forwarding may be advantageous to some file transmission use cases whereas for real-time video services such as live IPTV the focus is on low delay. Here only transfer of the MN's subscription context shall be considered for simplicity reasons. To decide on a multicast flow quality requirements dedicated flags may be defined to be stored in and retrieved from the common data base or policy storage. Deteiled considerations on these parameters are out of scope of this document. von Hugo, et al. Expires September 6, 2012 [Page 4] Internet-Draft Context Transfer for DMM Multicast March 2012 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. The following terms used in this document are to be interpreted as defined in existing proxy and client mobility protocols and in future upcoming Distributed Mobility Management (DMM) protocol specifications, see e.g. [15]: Distributed Access Router (DAR), Mobility Data Base (MDB), Mobile Node (MN), Proxy Care-of Address (Proxy-CoA), Mobile Node Identifier (MN-Identifier), Distributed Binding Update (DBU), and Distributed Binding Acknowledgement (DBA). von Hugo, et al. Expires September 6, 2012 [Page 5] Internet-Draft Context Transfer for DMM Multicast March 2012 3. Handover Process DAR is responsible for detecting the mobile node's movements to and from the access link and for initiating a per-flow binding registration either as mobility anchor (primary point of attachment). In case a MN attaches to the DAR which was already previously assigned to another (previous or primary) DAR (p-DAR) the new DAR (n-DAR) tracks the mobile node's movements to and from the access link and performs signaling of the status to that p-DAR and to a common MDB. In DMM Multicast, it SHOULD NOT be required for mobile nodes to initiate re-subscription to multicast channels, and DAR SHOULD keep multicast membership state for mobile nodes even if they attach a different DAR during the ongoing session. For multicast context transfer, an IGMP/MLD-based explicit membership tracking function [18] MAY be enabled on DAR (whether the DAR behaves as a router or proxy). The explicit tracking function enables a router to keep track of downstream multicast membership state created by downstream hosts attached on the router's link. When a mobile node attaches to a new network, thanks to the explicit tracking function, the p-DAR extracts the mobile node's multicast membership state from complete multicast membership state the p-DAR has maintained and transmits it to the n-DAR. The assumed architecture for a DMM-based multicast mobility is shown in Figure 1. +--------------------+ | Mobility Data Base | +--------------------+ / | \ / | \ / | \ / | \ +--------+ +--------+ + ------+ | DAR1 |______| DAR2 |____| DAR3 | | = p-DAR|______| = n-DAR| | | +--------+ +--------+ +-------+ | +----+ | MN | +----+ Figure 1: Distributed mobility for flat architecture von Hugo, et al. Expires September 6, 2012 [Page 6] Internet-Draft Context Transfer for DMM Multicast March 2012 3.1. Multicast Context Transfer Data Format Multicast Context Transfer Data (M-CTD) is a message used with CXTP to transfer multicast membership state from p-DAR to n-DAR. The following information is included in M-CTD to recognize mobile node's membership state. 1. Receiver address - indicates the address of the MN sending the Current-State Report. 2. Filter mode - indicates either INCLUDE or EXCLUDE as defined in [5]. 3. Source addresses and multicast addresses - indicates the address pairs the MN has joined. The M-CTD message MUST contain the 'A' bit set as defined for the CTD message format in [10] for to initiate the transmission of a reply message by the new DAR. The following information included in a reply to M-CTD (similar to the CTDR message defined in [10]) is used to request the old DAR to store still incoming multicast data, to forward them to the new DAR, and finally to leave the multicast group after successful handover from n-DAR to p-DAR. 1. Receiver address - indicates the address of the MN sending the Current-State Report. 2. Flag indicating the p-DAR to start (B) buffering the received multicast data (in case the new connection is not yet fully set up), to forward (F) the buffered data after successful handover, or to leave (L) the multicast groups unless there are still other active subscriptions for the corresponding groups on the p-DAR. 3. Source addresses and multicast addresses - indicates the address pairs the MN has joined. The M-CTDR message MUST contain the 'S' bit set as defined for the CTD message format in [10] for to indicate the successful reception of context data at the new DAR. 3.2. Multicast Context Transfer with MLD Proxy This section describes the case that DAR operates as an MLD proxy, as defined in [7] and specified in the base MultiMob solution [12]. von Hugo, et al. Expires September 6, 2012 [Page 7] Internet-Draft Context Transfer for DMM Multicast March 2012 The MLD listener handover with CXTP and MLD proxy shown in Figure 2 is defined as follows. 1. A MN is assumed to be attached to the p-DAR wishing to receive multicast content and sending the corresponding MLD Report. The serving p-DAR subscribes to the group as MLD proxy and forwards the multicast traffic to the MN via the access link. In case the MN's multicast session is completed while being attached to p-DAR no corresponding entry into the Mobility Data Base needs to be created (regular IPv6 routing). However in case the MN wants to maintain the multicast session (together with ongoing unicast connections) during movement it either registers the address configured at the p-DAR as home address, as described in [21] or the p-DAR has to create a binding entry in the central MDB as proposed e.g. in [20] or [16]. 2. When the MN moves to another DAR with the multicast session ongoing the p-DAR detects the detachment and subsequently sends a request to create a Binding Cache Entry for the MN in the MBD, denoted by BCE Create Request (BC-Req). 3. After attaching a new DAR, the mobile node sends a Router Solicitation (RS) as specified in [8]. In case the MN shall remain unaware of any change in connectivity the n-DAR has to identify the p-DAR address during retrieving the MN's BCE from the mobile node's MDB e.g. via newly specified Distributed Binding Update (DBU) and corresponding Acknowledgement (DBA). n-DAR then sends a request for context transfer (CT-Req) to the p-DAR as defined in [10]. Since the MN cannot initiate the related Context Transfer Activate Request (CTAR) message that may be sent by the MDB. In case the mobile node has the capability and the chance to signal to the p-DAR the link status and the potential new DAR address (e.g. as is specified in terms of Event Services by [9]) the p-DAR will send a CTAR message to n-DAR on behalf of the mobile node. Alternatively the p-DAR or the n-DAR may have information on potential DARs in their vicinity to which such a CTAR or CT-Req message may be multicasted. 4. p-DAR provides together with the other feature data the multicast states corresponding to the moving MN-Identifier to n-DAR. p-DAR utilizes a context transfer protocol to deliver MN's Policy Profile to n-DAR, and sends Multicast Context Transfer Data (M-CTD) (defined in Section 3.1) to n-DAR. von Hugo, et al. Expires September 6, 2012 [Page 8] Internet-Draft Context Transfer for DMM Multicast March 2012 5. If there are multicast channels the MN has subscribed but the n-DAR has not yet subscribed, n-DAR subscribes via sending (potentially aggregated) MLD [5][6] Membership Report messages (i.e. Join) to the corresponding MDB. 6. After successful completion of MN attachment the n-DAR replies to M-CTD with a Multicast Context Transfer Response message signalling the handover completion upon which p-DAR may leave the multicast group in case no other MN attached to p-DAR has subscribed to that group. MN p-DAR n-DAR MDB | | | | |-MLD Report->|==== MLD Report (aggregated Join) =======> | | | | |<------------|<=========== Multicast data ============== | | | | Detach | | | | | | | | |----- BC-Req ------------------------->| | | | | Attach | | | | | | | |------------- RS --------------->| | | | |------- DBU ------>| | | | | | | |<-------DBA--------| | | | | | |<----- CT-Req -------------------------| | | | | | |------ CXTP ------>| | | | M-CTD | | | | |=== MLD Report ===>| | | | | |<----------- RA -----------------| | | | | | | | |<= Multicast data =| | |<------ CXTP ------| | | | M-CTDR | | | | | | |<-------- Multicast data --------| | | | | | | |=== potential MLD Report (leave) =====>| | | | | Figure 2: MLD listener handover with CXTP and MLD proxy von Hugo, et al. Expires September 6, 2012 [Page 9] Internet-Draft Context Transfer for DMM Multicast March 2012 After MN attaches to n-DAR, the forwarded multicast data from p-DAR will be delivered to the MN immediately. Afterwards the current multicast data are delivered as received from MDB and the MN's multicast membership state at the p-DAR is cancelled. 3.3. Multicast Context Transfer with PIM-SM This section describes the case that DAR operates as a PIM-SM [4] router, as described in a proposed solution [13]. The MLD listener handover with CXTP and PIM-SM is identical as described in Section 3.2 except that instead of "MLD report (aggregated Join)" the DARs will send "PIM Join" messages and that the "MLD Report (leave)" , to be sent if there are no attached mobile nodes listening the multicast channels at p-DAR, is replaced by "PIM Prune" message. von Hugo, et al. Expires September 6, 2012 [Page 10] Internet-Draft Context Transfer for DMM Multicast March 2012 4. IANA Considerations TBD. von Hugo, et al. Expires September 6, 2012 [Page 11] Internet-Draft Context Transfer for DMM Multicast March 2012 5. Security Considerations TBD. von Hugo, et al. Expires September 6, 2012 [Page 12] Internet-Draft Context Transfer for DMM Multicast March 2012 6. Acknowledgements Many of the specifications described in this document are discussed and provided by the multimob mailing-list. Detailed comments by Luis Miguel Contreras Murillo are gratefully acknowledged. von Hugo, et al. Expires September 6, 2012 [Page 13] Internet-Draft Context Transfer for DMM Multicast March 2012 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [2] Perkins, C, Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [3] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [6] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 Protocols", RFC 5790, February 2010. [7] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [8] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010. [9] "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services, IEEE LAN/MAN Std 802.21-2008", January 2009. 7.2. Informative References [10] Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [11] von Hugo, D. and H. Asaeda, "Context Transfer Protocol extensions for Multicast", draft-vonhugo-multimob-CXTP-extension-01.txt (work in progress), January 2012. [12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) von Hugo, et al. Expires September 6, 2012 [Page 14] Internet-Draft Context Transfer for DMM Multicast March 2012 Domains", RFC 6224, April 2011. [13] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for PIM-SM", draft-asaeda-multimob-pmip6-extension-07.txt (work in progress), October 2011. [14] Schmidt, TC., Waehlisch, M., Koodli, R., and G. Fairhurst, "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", draft-schmidt-multimob-fmipv6-pfmipv6-multicast-05.txt (work in progress), November 2011. [15] Patil, B., Williams, C., and J. Korhonen, "Approaches to Distributed mobility management using Mobile IPv6 and its extensions", draft-patil-mext-dmm-approaches-02.txt (work in progress), October 2011. [16] Seite, P. and P. Bertin, "Distributed Mobility Anchoring", draft-seite-dmm-dma-00.txt (work in progress), February 2012. [17] Liu, D., Song, J., and W. Luo, "PMIP Based Distributed Mobility Management Appproach", draft-liu-dmm-pmip-based-approach-01.txt (work in progress), December 2011. [18] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", draft-ietf-pim-explicit-tracking-00.txt (work in progress), October 2011. [19] Contreras, LM., Bernardos, CJ., and I. Soto, "Rapid acquisition of the MN multicast subscription after handover", draft-contreras-multimob-rams-03.txt (work in progress), October 2011. [20] Bernardos, CJ., de la Oliva, A., Giust, F., and T. Melia, "A PMIPv6-based solution for Distributed Mobility Management", draft-bernardos-dmm-pmip-00.txt (work in progress), January 2012. [21] Bernardos, CJ., de la Oliva, A., and F. Giust, "A IPv6 Distributed Client Mobility Management approach using existing mechanisms", draft-bernardos-mext-dmm-cmip-00.txt (work in progress), March 2011. von Hugo, et al. Expires September 6, 2012 [Page 15] Internet-Draft Context Transfer for DMM Multicast March 2012 Authors' Addresses Dirk von Hugo Telekom Innovation Laboratories Deutsche-Telekom-Allee 7 Darmstadt 64295 Germany Phone: Email: Dirk.von-Hugo@telekom.de URI: Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-0882 Japan Email: asaeda@wide.ad.jp URI: http://www.sfc.wide.ad.jp/~asaeda/ Pierrick Seite France Telecom - Orange 4, rue du Clos Courtel BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange.com URI: von Hugo, et al. Expires September 6, 2012 [Page 16]