A channel-manageable IP multicast support framework for distributed mobility management

Abstract

Abstract-As the rapid increase of Internet traffic is becoming a serious problem, mobile Internet networks are moving towards flat architectures. Distributed mobility management (DMM) is expected to be one of the key technologies tackling the problem by distributing the data traffic concentrated on a centralized anchor to different access routers. For deploying IP multicasting on mobile networks, a Multicast Listener Discovery (MLD) Proxy is generally considered due to its lightweight feature compared to multicast routing protocols. Following DMM requirements being defined in IETF, an upstream interface of MLD Proxy on an access router is basically fixed towards mobile node (MN)'s anchor to keep the mobility state with unicast session in the same entity. It causes unnecessary multicast traffic due to multiple tunnels established with several access routers for common multicast channel so that this runs counter to the objective of the DMM. In this paper, we propose a channelmanageable IP multicast framework for distributed mobility management, called (CM-DMM), managing of all the multicast channels on Mobility Access Routers (MARs) and the control of which channel should be local or remote. We confronted the performance of CM-DMM against DMM with fixed MLD upstream decision towards each MN's mobility anchor, in terms of duplicate channels and traffic according to the MNs' movement and channel locality ratio. Simulation results demonstrate that CM-DMM is effective to highly reduce unnecessary multicast traffic relatively to DMM with fixed MLD upstream decision. Additional performance factors of CM-DMM are discussed, as well as considerations for its practical deployment in multicast/broadcast networks.

D3M: Multicast listener mobility support mechanisms over distributed mobility anchoring architectures

“…Similarly to MLD Proxy usage in PMIPv6, this problem is verified whenever multiple MLD Proxy instances run over a DMM router, since each is associated with a different upstream interface. In order to overcome this issues, in Jeon et al (2012), the coordination between the IGMP/MLD Proxy instances and the serving router was studied, which led to the definition of IP multicast architecture framework applying per-channel management. The simulation results showed that such approach could minimize duplicate traffic by means of a channel control server managing a multicast channel for a given serving router.…”

“…This protocol design may lead to duplicate traffic, where a serving DMM router receives multiple copies of the same multicast stream, one for each IGMP/MLD Proxy instance running on the router. Aiming to solve this issue by tackling the lack of coordination between the IGMP/MLD Proxy instances and the serving router, a channel-manageable IP multicast architecture framework has been presented in Jeon et al (2012). It solves the duplicate traffic issue by introducing a channel control server managing a multicast channel for a given serving router.…”

Efficient Multicast Content Delivery over a Distributed Mobility Management Environment

“…In [16], the authors introduce a framework managing all multicast channels and controlling which channel should be local or remote. In other words, the MAR will decide to get a multicast channel from the multicast infrastructure (for local content) or from the previous MAR (for remote content) to minimize the multicast traffic duplication.…”

“…A set of proposals has been introduced (mainly for PMIPv6) in which each of them aims at solving a couple of issues, for example: i) the multicast context transfer (CXT) for the service disruption and packet loss issue [11] [12]; ii) the multiple upstream interfaces support for the Internet Group Management Protocol (IGMP) / MLD Proxy for the tunnel convergence problem [13]; iii) the explicit tracking function for leave latency and waste of resources issue [14] [15]; and iv) the channel-manageable solution for both tunnel convergence and sub-optimal routing issue [16]. Yet, they fail to address all these issues at the same time.…”