MULTIMOB Group M. Kellil Internet Draft M. Boc Intended status: Informational C. Janneteau Expires: May 16, 2013 CEA LIST November 16, 2012 Group Communications in a PMIPv6 Domain with Partial Deployment of Multicast 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), 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 April 16, 2013. 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. Kellil et al. Expires May 16, 2013 [Page 1] Internet-Draft Group Communications in PMIPv6 November 2012 Abstract Various approaches have been proposed to support multicast in PMIPv6 domains. However, the problem of partial deployment of multicast in the PMIPv6 domain has not been considered. In particular, the proposed approaches typically assume that all the MAGs of the PMIPv6 domain are multicast-capable. The present work aims at carrying out the case where some of the PMIPv6 domain's MAGs are not necessarily multicast-capable. Table of Contents 1. Introduction ................................................ 3 2. Proposed Solution ........................................... 3 2.1. Assumptions ............................................ 3 2.2. Node Subscription ...................................... 5 2.2.1. Option 1 - Non multicast-capable MAG .............. 5 2.2.2. Option 2 - Configurable MAG ....................... 7 2.2.3. Option 3 - Multicast-capable MAG .................. 8 2.3. Data Forwarding ........................................ 8 2.3.1. Option 1 - Non multicast-capable MAG .............. 9 2.3.2. Option 2 - Configurable MAG ....................... 9 2.3.3. Option 3 - Multicast Capable MAG .................. 9 2.4. Node Handover .......................................... 9 2.5. Node Unsubscription .................................... 9 2.5.1. Option 1 - Non multicast-capable MAG ............. 10 2.5.2. Option 2 - Configurable MAG ...................... 10 2.5.3. Option 3 - Multicast-Capable MAG ................. 10 3. Security Considerations .................................... 10 4. IANA Considerations ........................................ 10 5. References ................................................. 10 5.1. Normative References................................... 10 5.2. Informative References ................................ 11 6. Acknowledgments ............................................ 11 Kellil et al. Expires May 16, 2013 [Page 2] Internet-Draft Group Communications in PMIPv6 November 2012 1. Introduction The present work seeks into addressing the case of partial deployment of multicast in PMIPv6 domains while enabling end-to-end group communications. The proposed approach may be useful for network operators that may be reluctant in deploying multicast in the whole PMIPv6 domain for different reasons like deployment cost, security policy/access control constraints, service provisioning constraints, QoS, etc. For such operators, the present approach may represent a good short/mid- term multicast deployment strategy in PMIPv6 (for an experimental purpose, for instance). Various approaches have been proposed to support multicast in PMIPv6 domains. They all assume that multicast is supported in the whole PMIPv6 domain. For instance, the document [RFC 6224] describes some techniques for deploying multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. In the proposed solution, the LMA implements the function of the designated multicast router, MLD querier, and optionally an MLD proxy. According to MLD reports received from a MAG (on behalf of the MNs), the LMA manages multicast forwarding states at its corresponding downstream tunnel interfaces. Also, the MAG performs MLD proxy functions. A MAG that does not support multicast operations will discard MN's subscription message. This solution does not address the case of a partial deployment of multicast in the PMIPv6 domain (e.g., scenarios where some MAGs of the PMIPv6 domain do not support multicast operations). Also, other approaches like [Saada2012] [Hui2012] seek into optimizing mobility of multicast receivers in terms of handover latency and tunneling overhead at the MAG, yet such approaches do not solve the problem of partial deployment of multicast in the PMIPv6 domain. 2. Proposed Solution 2.1. Assumptions The solution leverages SIP protocol [RFC 3261] to enable the LMA storing information about active multicast groups. Therefore, it is assumed that a SIP framework is deployed over the PMIPv6 domain. In this framework the LMA plays the role of a SIP proxy. This proxy is of a stateful type so as it can maintain states of active multicast groups and associated MNs. Also, the SIP server is present in the SIP framework, yet the SIP server will not be discussed in this document because it is not directly involved in the functional Kellil et al. Expires May 16, 2013 [Page 3] Internet-Draft Group Communications in PMIPv6 November 2012 scheme of the present approach. In addition, the MN is assumed to perform standard PMIPv6 operations for network attachment and handover [RFC 5213]. Also, the MN is assumed to be a multicast-capable node (multicast receiver) as well as a SIP client. However, the MN is not aware of any possible multicast capability on the MAG. This avoids the modification of Neighbor Discovery protocol [RFC 4861]. Also, the LMA is assumed to be a multicast anchor point in that it implements the operations defined in RFC 6224 (MLD Querier, optional MLD proxy, and multicast router). The LMA also manages a multicast subscription list (MSL) that has the following structure: , , , , There may be multiple MAGs in the PMIPv6 domain. Some of these MAGs are multicast-capable whereas others are standard PMIPv6 MAGs. Also, some of these standard PMIPv6 MAGs may be configured with a mapping that associates a UDP port number to one or more multicast addresses. In view of that, three types of MAG are to be considered: non multicast capable MAG, configurable MAG, and multicast-capable MAG. o Non multicast capable MAG (NM): in this option the MAG supports conventional PMIPv6 operations only, as per RFC 5213. o Configurable MAG (CM): a MAG that supports conventional PMIPv6 operations and stores a structure that maps an input UDP port number to a multicast address. In addition, it is capable of forwarding multicast packets to the MNs attached to its network. The MAG's input UDP port number is known in advance by both the MAG and LMA. o Multicast capable MAG (MM): a MAG that supports multicast operations as indicated in RFC 6224. Also, in this solution it is assumed that the LMA knows the capability of each MAG in terms of multicast support. Also, it is assumed that each time the LMA receives a PBU message from a MAG, it internally checks for MAG's capability. To store the information on the MAG capability in terms of multicast support, the standard PMIPv6 binding cache structure may need to be modified so as each MAG address will be associated (e.g., will be pointing) to a MAG capability value NM, CM, or MM. Kellil et al. Expires May 16, 2013 [Page 4] Internet-Draft Group Communications in PMIPv6 November 2012 2.2. Node Subscription First, the MN attaches to the PMIPv6 network using the standard procedure defined in RFC 5213 (cf. figure 1). Once the MN has configured its IP address, it initiates the group subscription procedure, by sending a SIP invite message to the LMA, which acts as a SIP proxy. The SIP invite message includes the multicast address of the desired group as well as the MN-ID. When the LMA receives the SIP invite message from MN, it stores the MN-ID and multicast address in its multicast subscription list (MSL). It is worth mentioning that since the LMA holds the couple ", " in its binding cache as well, the present solution proposes that each time the LMA notices that a new MN has registered through a standard PMIPv6 procedure, it checks whether this MN is registered in the MSL list. If so, the LMA then checks if the said MSL entry includes the MN's MAG address. If the MAG address does not exist, the LMA will add it in the MSL entry. If MN's MAG address is already in the MSL list, no further operation is needed in the MSL entry. In addition to its registration with the LMA, the MN sends an (unsolicited) MLD Report message on its link, without caring, though, whether the MAG is multicast-capable or not. These options are discussed in what follows. 2.2.1. Option 1 - Non multicast-capable MAG When the LMA receives a PBU message from a MAG and notices that the said MAG is not multicast-capable, it checks whether the MN-ID included in the PBU message is registered in one of the entries of its multicast subscription list (MSL). If so, the LMA updates the associated MSL entry with the MAG's IP address, and attaches to the multicast tree on behalf of the MN (cf. figure 2). In addition, the LMA establishes a double IP tunneling towards the MN (besides the LMA's standard PMIPv6 tunnel). The inner tunnel will end at the MN's IP address, and the outer tunnel will end at MAG's IP address. Of course, this double IP tunneling is transparent to the MAG, since the inner header includes MN's IP address, while the outer tunnel (obviously) terminates at the MAG's PMIPv6 tunnel interface. If the MN-ID is not in the MSL list, no multicast-specific operation is needed on the LMA. On the other hand, when the MAG receives MN's Report, it will ignore it. Kellil et al. Expires May 16, 2013 [Page 5] Internet-Draft Group Communications in PMIPv6 November 2012 +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | MN Attached | | | | | | MN Attached Event from MN/Network | | (Acquire MN-Id and Profile) | | | | |--- Rtr Sol --------->| | | | | | |--- PBU ------------->| | | | | | Accept PBU | | (Allocate MN-HNP(s), Setup BCE and | | Tunnel) | | | | |<------------- PBA ---| | | | | Accept PBA | | (Set Up Tunnel and Routing) | | | | | | MN-Id is in MSL | | & | | MAG not | | mcast-capable is TRUE | | & | | update MSL entry with | | MAG' IP address | | & | | attach mcast tree | | --------------------- | |======================|====== Double Tunnel===| | | --------------------- | | | | |<--------- Rtr Adv ---| | | | | IP Address | | Configuration | | | | | | Join (G) | | | -------------------->| | | ignore | | | | Figure 1 PMIPv6-based MN's Group Join Procedure - Case of Non- Multicast Capable MAG Kellil et al. Expires May 16, 2013 [Page 6] Internet-Draft Group Communications in PMIPv6 November 2012 2.2.2. Option 2 - Configurable MAG When the LMA receives a PBU message from a MAG and notices that the said MAG is a configurable MAG, it checks whether the MN-ID included in the PBU message is registered in one of the entries of its multicast subscription list (MSL). If so, the LMA updates the associated MSL entry with the MAG's IP address, and attaches to the multicast tree on behalf of the MN (cf. figure 3). In addition, the LMA establishes a unicast tunnel towards the MAG (besides the standard PMIPv6 tunnel) and sets a dedicated destination port number to the said tunnel. In a preferred setting, there is a common tunnel (and thus a common port number) between LMA and MAG for all the multicast addresses. The use of one tunnel (and thus one port number) between LMA and MAG per multicast address is kept optional. If the MN-ID is not in the MSL list, no multicast-specific operation is needed on the LMA. On the other hand, when the MAG receives MN's MLD Report, it will ignore it. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | MN Attached | | | | | | MN Attached Event from MN/Network | | (Acquire MN-Id and Profile) | | | | |--- Rtr Sol --------->| | | | | | |--- PBU ------------->| | | | | | Accept PBU | | (Allocate MN-HNP(s), Setup BCE and | | Tunnel) | | | | |<------------- PBA ---| | | | | Accept PBA | | (Set Up Tunnel and Routing) | | | | | |== Bi-Dir Tunnel(1)===| |<--------- Rtr Adv ---| | | | | IP Address | | Configuration | | | | MN-Id is in MSL | | & Kellil et al. Expires May 16, 2013 [Page 7] Internet-Draft Group Communications in PMIPv6 November 2012 | | Configurable MAG | | is TRUE | | & | | update MSL entry with | | MAG' IP addres | | & | | attach mcast tree | | | | | | | |== Bi-Dir Tunnel(2)===| | | dst_port_nb= port_x | | for Bi-Dir Tunnel(2) | | | | | | | Join (G) | | | -------------------->| | | ignore | | | | Figure 2 PMIPv6-based MN's Group Join Procedure - Case of Configurable MAG 2.2.3. Option 3 - Multicast-capable MAG When the LMA receives a PBU message from a MAG and notices that the said MAG is multicast-capable, it checks whether the MN-ID included in the PBU message is registered in one of the entries of its multicast subscription list (MSL). If so, the LMA updates the associated MSL entry with the MAG' IP address, and carries on the rest of the MN registration operation according to RFC 6224 (i.e., receive and process aggregated MLD Reports (or Aggregated Join message) from the MAG, attach to the multicast tree on behalf of the MN, establish appropriate tunnel with the MAG). If the MN-ID is not in the MSL list, no multicast-specific operation is needed on the LMA. On the other hand, when the MAG receives MN's MLD Report, it will process it according to RFC 6224 specification (MLD Reports aggregation and forwarding to LMA). 2.3. Data Forwarding When the LMA receives a multicast packet, it checks its MSL list for the entries that match the packet's multicast address. For each matching entry, the LMA checks whether the associated MAG is multicast-capable or not. Kellil et al. Expires May 16, 2013 [Page 8] Internet-Draft Group Communications in PMIPv6 November 2012 2.3.1. Option 1 - Non multicast-capable MAG If the MAG is not multicast-capable, the LMA will utilize a double- tunneling to send the multicast packet towards the MN. The outer IP header of the tunnel includes MAG's address as a destination. The inner IP header of the tunnel includes MN's IP address so as multicast packet forwarding from LMA to MN via the MAG will be transparent to the said MAG. When the MAG receives the multicast packet from the LMA via its PMIPv6 tunnel interface, it removes the outer header and forwards the resulting packet to the MN (as per RFC 5213). 2.3.2. Option 2 - Configurable MAG If the MAG is configurable, the LMA will tunnel the multicast packet towards the MAG using the dedicated UDP port number. When the MAG receives the multicast packet from the LMA via a dedicated input UDP port, it removes the outer header and forwards the resulting (multicast) packet on its downstream interface. 2.3.3. Option 3 - Multicast Capable MAG Data forwarding procedure in option 3 is similar to that of RFC 6224. 2.4. Node Handover MN handover to a new network associated to a new MAG: nMAG is quite similar to that of the MN subscription phase (option 1, option 2 & option 3), excluding the SIP procedure, which of course is not needed for the handover phase. In addition, the LMA in the MN handover phase has to update the associated MSL entry with the nMAG' IP address (this update is done when the LMA checks the PBU's MN-ID in the MSL list). Furthermore, in the handover phase there may be no need to (re)build the multicast path (from the multicast tree) towards the LMA (since the said path is (normally) already built). 2.5. Node Unsubscription When an MN wishes to leave a multicast group, it notifies the LMA via SIP Bye message and sends an MLD Exclude/Done on its link. The SIP message contains the multicast address of the group to be left by MN as well as the MN-ID. Kellil et al. Expires May 16, 2013 [Page 9] Internet-Draft Group Communications in PMIPv6 November 2012 When the LMA receives the SIP Bye message, it checks MN's ID and the multicast address against the MSL entries. If an entry is found, the LMA removes it and updates the multicast routing state accordingly (ex. the LMA removes the multicast forwarding state for the said multicast address if no more MNs are associated to this multicast address). On the MAG's side, however, three options are to be distinguished. 2.5.1. Option 1 - Non multicast-capable MAG When a non-multicast capable MAG receives an MLD Exclude/Done message, it ignores it. 2.5.2. Option 2 - Configurable MAG When a configurable MAG receives an MLD Exclude/Done message, it ignores it. 2.5.3. Option 3 - Multicast-Capable MAG When a multicast-capable MAG receives an MLD Exclude/Done message, the rest of the procedure follows RFC 6224's operations (if necessary, update of the MAG's membership database and transmission of MLD Exclude/Done via the MAG-to-LMA interface towards the LMA, which then terminates multicast forwarding). 3. Security Considerations The security considerations are the same as that covered by [RFC 6224] and [RFC 3261]. 4. IANA Considerations If this solution is to be pursued, IANA would be kindly requested to reserve a default port to be used in the case of configurable MAG. 5. References 5.1. Normative References [RFC 5213] Gundavelli, S. et al., "Proxy Mobile IPv6", RFC 5213, August 2008. Kellil et al. Expires May 16, 2013 [Page 10] Internet-Draft Group Communications in PMIPv6 November 2012 [RFC 3810] Vida, R. et al., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC 6224] Schmidt, T. et al., "Base Deployment for Multicast Listener Support", RFC 6224, April 2011. [RFC 3261] Rosenberg, J. et al., " SIP: Session Initiation Protocol", RFC 3261, June 2002. 5.2. Informative References [Saada2012] Asaeda, H. et al., "Multicast Routing Optimization by PIM-SM with PMIPv6", Internet Draft, March 2012, (Work in Progress). [Hui2012] Hui, M. et al, "Fast Handover for Multicast in Proxy Mobile IPv6", Internet Draft, March 2012, (Work in Progress). [RFC 4861] Narten, T. et al. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 6. Acknowledgments The work presented in this document has been supported by the European Celtic project MEVICO which aims researching the network aspects of the 3GPP LTE-mobile broadband network for its evolution in the mid-term in 2011-2014. Kellil et al. Expires May 16, 2013 [Page 11] Internet-Draft Group Communications in PMIPv6 November 2012 Authors' Addresses Mounir Kellil CEA, DRT, LIST, Communicating Systems Laboratory, Point Courrier 173, Gif-sur-Yvette, F-91191 France Email : mounir.kellil@cea.fr Mathias Boc CEA, DRT, LIST, Communicating Systems Laboratory, Point Courrier 173, Gif-sur-Yvette, F-91191 France Email: mathias.boc@cea.fr Christophe Janneteau CEA, DRT, LIST, Communicating Systems Laboratory, Point Courrier 173, Gif-sur-Yvette, F-91191 France Email: christophe.janneteau@cea.fr Kellil et al. Expires May 16, 2013 [Page 12]