MULTIMOB Group S. Figueiredo Internet Draft R. L. Aguiar Intended status: Standards Track Universidade de Aveiro Expires: August 12, 2012 S. Jeon Instituto de Telecomunicacoes March 12, 2012 IP Multicast Use Case Analysis for PMIPv6.based Distributed Mobility Management draft-sfigueiredo-multimob-use-case-dmm-01.txt Status of this Memo This Internet-Draft is submitted to IETF 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 August 12, 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 Figueiredo, et al. Expires August 12, 2012 [Page 1] Internet-Draft Use Cases for Multicast DMM March 2012 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract As mobile networks are moving towards distributed mobility management, the application of IP multicast is needed to provide efficient content delivery on the network. This document describes use cases when IP multicast is applied on PMIPv6-based DMM, and analyzes problems focused on user plane issues. Table of Contents 1. Introduction...................................................3 2. Conventions and Terminology....................................3 3. Use Cases Description..........................................4 3.1. Multicast listener support................................4 3.1.1. MLD-P in MAR.........................................4 3.1.1.1. Duplicated Traffic..............................5 3.1.1.2. Non-optimal routing.............................6 3.1.2. Multicast Router in MAR..............................7 3.2. Multicast sender support..................................7 3.2.1. MLD-P in MAR.........................................7 3.2.1.1. Triangular routing..............................8 3.2.2. Multicast Router in MAR.............................10 4. IANA Considerations...........................................11 5. Security Considerations.......................................11 6. References....................................................11 6.1. Normative References.....................................11 6.2. Informative References...................................11 Figueiredo, et al. Expires August 12, 2012 [Page 2] Internet-Draft Use Cases for Multicast DMM March 2012 1. Introduction As a consequence of the forthcoming multimedia avalanche, several optimization mechanisms are being considered towards efficient and resilient mobile networks. As analyzed in [DDMM-MI], current IP mobility management solutions have limitations in supporting efficient management and deployment. Thus, several proposals aiming at the distribution of the mobility management functions (e.g [DDMM- FP] were presented. The problems resulting from the application of mobility solutions in multicast traffic are known, affecting its efficiency and leading to non-negligible service disruption, reported among others ([IPMM][RFC5757]). Nevertheless, it is still not clear how the change from centralized to distributed mobility solutions may affect IP multicast support. This document briefly describes use cases of IP multicast in a PMIPv6-based DMM environment, and analyses consequent problems. Both listener and sender perspective are studied, with either MLD Proxy or Multicast Router functionality deployed at the Mobility Access Router (MAR). 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 [RFC2119]. This document uses the terminology defined in [RFC5213], [RFC6275], and [RFC3810], and [RFC4601]. Specifically, the definition of PMIPv6 domain is reused from [RFC5213] and reproduced here for completeness. - Mobility Access Router (MAR): A router with the capability of acting both as a mobility anchor and as an access router, in a per flow basis. - Previous Mobility Access Router (P-MAR): The MAR where the MN was attached to previously to the network-layer mobility process, and that may be acting as an anchor for one or multiple flows. - New Mobile Access Gateway (N-MAR): The MAR to which the MN is currently attached, providing the access functionality and thus delivers all the flows destined to the MN. - Multicast Listener Discovery Proxy (MLD-P): An entity following [RFC4605]. Figueiredo, et al. Expires August 12, 2012 [Page 3] Internet-Draft Use Cases for Multicast DMM March 2012 3. Use Cases Description This draft focuses on describing problems that may occur when deploying IP multicast on a general PMIPv6-derived DMM architecture. As there is not yet a fully specified unicast DMM protocol, the unicast DMM concept used in this document is assumed as follows: MAG and an LMA functionalities defined in [RFC5213] are equipped within a same physical entity, called MAR. A MAR provides tunnel-based forwarding to provide a home network prefix (HNP)-based flow with the necessary IP session continuity whenever the MN moves to another MAR. We separate the use cases in multicast listener and multicast sender support. 3.1. Multicast listener support 3.1.1. MLD-P in MAR Once a MN initially attaches to the P-MAR (as shown in Figure 1), it receives a home prefix address, which will be associated with communications started at that MAR. Detecting the new logical link, the P-MAR transmits to it a general MLD Query message, to which the MN will not yet reply. Thus, the P-MAR adds the downstream logical link to the MLD-P instance with uplink to the multicast infrastructure. When the MN intends to start receiving the multicast session, it will send an unsolicited MLD Report. On receiving the latter message, the MLD-P tries to join the multicast channel(s) by sending an aggregated MLD Report (with other MN's interests) through the MLD-P upstream interface. When the joining procedure ends, multicast data is transmitted through the same interface. Figueiredo, et al. Expires August 12, 2012 [Page 4] Internet-Draft Use Cases for Multicast DMM March 2012 +----------------+ | Multicast | | Infrastructure | +----------------+ * * (S,G) * +----------+ +----------+ | P-MAR |---------------| N-MAR | | |***************| | | (MLD-P) |---------------| (MLD-P) | +----------+ +----------+ * * * * +------+ +------+ | MN | -----> | MN | +------+ +------+ Figure 1 Multicasting architecture using distributed mobility management When the MN moves from P-MAR, the N-MAR is required to establish a tunnel for IP session continuity of the flows being sent towards the MN's HNP assigned by the P-MAR. This implies that N-MAR determines the MNs previous HNPs, being the exact method through which this is achieved out of scope of this document. Following the operation of the MLD-P [RFC4605], after the bidirectional tunnel establishment, the following process takes place. First, the N-MAR sends a General MLD Query, and verifies whether the MN is admissible for multicast sessions. If so, the MLD-P at the N-MAR adds the downstream interface corresponding to the MN, and configures the upstream interface towards the MN's P-MAR. Like in PMIPv6 base solution for multicast support [RFC6224], this is simple and applicable as a network-based multicast DMM approach. However, this approach leads to a couple of relevant issues. 3.1.1.1. Duplicated Traffic One of those problems is duplicated traffic, a result of the tunnel convergence problem occurring in [RFC6224]. As shown in Figure 2, MN1 and MN3, which moved from MAR1 and MAR3, respectively, are currently located at the MAR2. Through respective established tunnels, they receive multicast packets of the same channel through different anchoring MARs. This causes duplicated traffic, converging to the MAR2, with the magnitude of replicated traffic being much bigger than that of PMIPv6. This consideration is done assuming that the number Figueiredo, et al. Expires August 12, 2012 [Page 5] Internet-Draft Use Cases for Multicast DMM March 2012 of MARs in future DMMdomains will be much larger than that of LMAs at core level within a PMIPv6 domain. As referred, when a MN first subscribes multicast content, its current MAR's MLD-P will forward its subscription to the multicast infrastructure. As such, an extra duplication factor may occur, if the subscription being done is already being received from one or multiple tunnels due to other listeners (refer to MN2 from Figure 2 for an example). +----------------+ | Multicast Tree | * +----------------+ * * * * * * * * * * (S,G) * (S,G) * * (S,G) * * * +----------+ (-->) +----------+ (<--) +----------+ | MAR1 |---------| MAR2 |---------| MAR3 | | |*********| |*********| | | (MLD-P) |---------| (MLD-P) |---------| (MLD-P) | +----------+ Tun.1 +----------+ Tun.2 +----------+ * * * * * * * * * +---+ move +---+ +---+ +---+ move +---+ |MN1| ---> |MN1| |MN2| |MN3| <--- |MN3| +---+ +---+ +---+ +---+ +---+ (<--/-->) : direction of the multicast packet flow Figure 2 Data replication 3.1.1.2. Non-optimal routing Another issue is non-optimal routing (Figure 3). If we consider a significantly large domain, there is the possibility that the multicast packets need to traverse a long distance, depending on the setup of the upstream interface of MLD-P instance, even if the current MAR is connected to the multicast infrastructure. If an operator wants to deploy a MLD-P instance with the upstream interface towards multicast source or multicast routing network, for each MAR, this issue doesn't happen. Such an approach is extremely simple and Figueiredo, et al. Expires August 12, 2012 [Page 6] Internet-Draft Use Cases for Multicast DMM March 2012 mobility-agnostic, but there may occur media synchronization issues and service disruption during handoff. +----------------+ | Multicast | | Infrastructure | +----------------+ * * (S,G) * +----------+ +----------+ | P-MAR |------ ------| N-MAR | | |****** ... ******| | |(MLD-P) |------ ------| (MLD-P) | +----------+ +----------+ * * * * +------+ +------+ | MN | -----> | MN | +------+ +------+ Figure 3 Non-optimal routing problem 3.1.2. Multicast Router in MAR TBD 3.2. Multicast sender support In order to provide sender multicasting support, a MAR may be required to act as MLD-P or multicast router. Depending on the equipped functions, we describe issues relative to multicast sender support. 3.2.1. MLD-P in MAR In order for the multicast content to reach the multicast tree, the MLD-P SHOULD configure its upstream interface towards a MR [PM-HOME]. In the case of MR or MAR, it MAY act as the Rendezvous Point (RP) but Figueiredo, et al. Expires August 12, 2012 [Page 7] Internet-Draft Use Cases for Multicast DMM March 2012 cause frequent multicast tree reconstruction and associated service disruptions whenever the MN moves. +------+ +----------------+ | RP |---------| Multicast | +------+ | Infrastructure | * +----------------+ * (S,G) | * | +----------+ +----------+ | P-MAR |----------| N-MAR | | |**********| | | (MLD-P) |----------| (MLD-P) | +----------+ +----------+ * * * * +------+ +------+ | S | ----> | S | +------+ +------+ Figure 4 Multicast sender mobility 3.2.1.1. Triangular routing When a source is transmitting a multicast session and a mobility process takes place, i.e the session is anchored through another MAR (MAR1 in Figure 5), then multicast data will be sent through the mobility tunnel between N-MAR (MAR2) and P-MAR (MAR1). A listener (L1) that subscribed to the source's channel as is attached at the same MAR (MAR2) will receive the multicast content from multicast infrastructure. Therefore the traffic will traverse a non-optimal route between the source and the listener. Figueiredo, et al. Expires August 12, 2012 [Page 8] Internet-Draft Use Cases for Multicast DMM March 2012 +------+ +----------------+ | RP |*********| Multicast | +------+ | Infrastructure | * +----------------+ * (S,G) * * * +----------+ +----------+ | MAR1 |-------| MAR2 | | |*******| | | (MLD-P) |-------| (MLD-P) | +----------+ +----------+ * * * * * * +------+ move +------+ +-----+ | S | ---> | S | | L1 | +------+ +------+ +-----+ Figure 5 Triagular routing after source mobility The same problem also occurs in the opposite process, i.e. if a multicast source starts transmitting multicast content at a MAR, and a listener moves to the same MAR while receiving the source's content (Figure 6). +------+ +----------------+ | RP |*********| Multicast | +------+ | Infrastructure | * +----------------+ * (S,G) * * * +----------+ +----------+ | MAR1 |-------| MAR2 | | |*******| | | (MLD-P) |-------| (MLD-P) | +----------+ +----------+ * * * * * * +------+ +----+ move +----+ | S | | L1 | <--- | L1 | +------+ +----+ +----+ Figure 6 Triangular routing after listener mobility Figueiredo, et al. Expires August 12, 2012 [Page 9] Internet-Draft Use Cases for Multicast DMM March 2012 When the source and the listener are within a same MAR (MAR2)if both the source and listener try to start the session and receive it, respectively at MAR2, the traffic will be optimally sent to the listener. As the traffic reaches the MLD-P via the downstream interface to which the source is attached, it will be sent through the interface to which the listener sent the MLD Report. However, if the source and the listener move to different MARs, the traffic will traverse the following non-optimal path, even though they share a common MAR2: Source -> MAR1 -> MAR2 -> Multicast Tree -> MAR2 -> MAR3 This problem is depicted in Figure 7. +----------------+ | Multicast Tree | +----------------+ * * * * * * * * * * +----------+ (-->) +----------+ (-->) +----------+ | MAR1 |---------| MAR2 |---------| MAR3 | | |*********| |*********| | | (MLD-P) |---------| (MLD-P) |---------| (MLD-P) | +----------+ Tun.1 +----------+ Tun.2 +----------+ * * * * * * * * * * * * +---+ move +---+ +---+ move +---+ | S | <--- | S | | L | --> | L | +---+ +---+ +---+ +---+ (<--/-->) : direction of the multicast packet flow Figure 7 Non-optimal routing due to mobile sender 3.2.2. Multicast Router in MAR TBD Figueiredo, et al. Expires August 12, 2012 [Page 10] Internet-Draft Use Cases for Multicast DMM March 2012 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations TBD 6. References 6.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6," IETF RFC 3810, June 2004. [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, August 2008. [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) Based Multicast Forwarding ("IGMP/MLD Proxying")", IETF RFC 4605, August 2006. [RFC4601] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 6.2. Informative References [RFC5757] T. Schmidt, M. Waehlisch, G. Fairhurst, Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey, RFC 5757, February 2010. Figueiredo, et al. Expires August 12, 2012 [Page 11] Internet-Draft Use Cases for Multicast DMM March 2012 [RFC6224] T. Schmidt, M. Waehlisch, S. Krishnan, "Base Deployment for Multicast Listener Support in PMIPv6 Domain,", RFC 6224, April 2011. [DDMM-FP] P. Bertin, S. Bonjour, and J.-M., Bonnin, "A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures," Proc. of NTMS 2008. , November 2008. [DDMM-MI] H. A. Chan, H. Yokota, J. Xie, P. Seite, D. Liu, "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues", Journal of Communications, vol. 6, no. 1, pp. 4-15, February 2011. [IPMM] I. Romdhani, M. Kellil, and H. Lach, "IP Mobile Multicast : Challenges and Solutions," IEEE Communications Surveys & Tutorials, vol. 6, no. 1, pp. 18-41, 2004. [PM-HOME] S. Jeon, N. Kang, and Y. Kim, "Mobility Management based on Proxy Mobile IPv6 for Multicasting Services in Home Networks," IEEE Transactions on Consumer Electronics (TCE), vol. 55, no. 3, pp. 1227-1232, August 2009. Figueiredo, et al. Expires August 12, 2012 [Page 12] Internet-Draft Use Cases for Multicast DMM March 2012 Authors' Addresses Sergio Figueiredo Universidade de Aveiro 3810-193 Aveiro, Portugal E-mail: sfigueiredo@av.it.pt Seil Jeon Instituto de Telecomunicacoes Campus Universitario de Santiago 3810-193 Aveiro, Portugal E-mail: seiljeon@av.it.pt Rui L. Aguiar Universidade de Aveiro 3810-193 Aveiro, Portugal E-mail: ruilaa@ua.pt Figueiredo, et al. Expires August 12, 2012 [Page 13]