IP Multicast Dynamic Mapping in Heterogeneous Environments

The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07) IP MULTICAST DYNAMIC MAPPING IN HETEROGENEOUS ENVIRONMENTS Diogo Gomes Rui L. Aguiar Instituto de Telecomunicações, Universidade de Aveiro Aveiro, Portugal ABSTRACT Multimedia group communication over IP is an advanced service gaining growing interest from broadcast, fixed and mobile network operators. Next Generation Networks (NGN) will require that IP based multimedia services to be efficiently delivered to groups over heterogeneous networks with QoS. Although being acknowledged as the most efficient way of delivering group communication in packet switched networks, IP multicast still faces some problems associated with QoS that have limited its success in the past. Furthermore the nonexistence of true multicast in wireless technologies has led to an inefficient mapping between the IP and wireless layers. This paper proposes a technique for efficient dynamic mapping of IP Multicast, optimizing its usage for NGN. This technique is evaluated by a prototype on a WiFi environment. I. INTRODUCTION Recent developments in technologies and business models for telecom operators have re-enacted IP multicast as an effective technique of delivering content to a broad set of end-users. Group communications are now seen as promising services by all operators - and not only broadcast ones - a situation that arouse by the increasing integration of communications across platforms. IPTV is one of the main services deployed by telecom operators with the so called “triple play” offerings. It constitutes the basic group communication service where registered and authorized end-users receive a real-time IP based multimedia stream at the contracted QoS level. For heterogeneous environments, IP Multicast provides a common abstraction essential for the service provider: regardless of the technology, group management is handled uniformly. Although the most efficient way of delivering such service is IP multicast, its mass exploitation has been limited due to inefficient access control, and insufficient QoS mechanisms. Furthermore, this same uniformity of IP multicast does not allow for an optimum exploitation of the specificities of each technology (e.g. for resource management), in particular in wireless networks. Wireless technologies can deeply influence multicast service capabilities in many ways, such as the unidirectional characteristics of DVB channels or the bandwidth limited broadcast channel of UMTS. This paper aims to exploit wireless technology features for improving QoS support and radio resource management under this desired common IP Multicast framework. In section II of this paper we will address the state of the art and related work to solve the QoS problems of IP multicast. In section III we present our proposal, which aims to allow the flexible mapping of IP multicast into a diversity of 1-4244-1144-0/07/$25.00 ©2007 IEEE. potential radio bearers/channels. We conclude the paper with sections IV and V, respectively an evaluation of a WiFi-based prototype of our proposal and final conclusions. II. STATE OF THE ART AND RELATED WORK Delivering content to a group has for long been a challenge in IP networks. In its original work, Dearing [1] proposed a technique for the transmission of an IP datagram to a "host group" composed of one or many host identified by an IP address. This initial work mainly focused in the need to efficiently use network resources to deliver the same content to a group of hosts, and did not take into consideration issues such as security and QoS. IP Multicast scalability relied in not requiring prior knowledge of whom or how receivers behaved. It uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers. The routers in the network take care of replicating the packet when necessary to reach multiple receivers. [1] was also one of the first works to implicitly separate IP address from the host identifier, since in IP multicast the IP address identifies a dynamic group and not an end-host. From this pioneering work, several solutions for scalable and efficient mechanisms of content delivery to a large audience have been proposed (e.g. [2],[3]). Commercially IP Multicast has not faced the expected success mostly due to security concerns and lack of QoS support. An operator willing to deploy e.g. IPTV services over IP multicast requires that only authorized users should be able to subscribe and access to the multicast group. Since authorization is performed on a per user basis, through tight control of the multicast subscription mechanism in the access router, operators can limit unauthorized access to a group to certain degree [6]. But unless multicast content is also protected through cryptographic mechanisms, a nearby user can listen to the multicast content that is being locally broadcast to an authorized user (this is sometimes referred to as the «Best-friend» problem). Another important issue is QoS assurances. In the common IPTV scenario, a source (Content Provider) sends a single multimedia stream of IP packets to a group, without identifying who belongs to the group. Thus, IP multicast listeners cannot reply back to the source with flow control information, and although some work is being carried on scalable flow control mechanisms for IP multicast [4] no standardized solution exists to date. Note that a scalable flow control mechanism is not the only possible solution, e.g. the IETF Reliable Multicast Transport group proposes NACK based protocols and Forward Error Correction (FEC) algorithms, by which listeners can recover from packet loss in the media [5]. The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07) With many of IP Multicast problems due to the shared transport channel, the idea of using P2P networks and their multiple one-to-one transport channels has sprung in the community, with multicast overlay networks over P2P [7][8],. Most of these solutions prove to be scalable and do not face the same QoS and Security problems as native IP multicast. As problems, we lack real time support (media is re-broadcasted over several nodes), inefficient usage of network resources (content must travel through several bottlenecks in access several times), and lack of privacy (content is usually cached in each node). Albeit all these technical hurdles, industry still pushes a strong use-case for IPTV services, with some 3G operators in Europe already providing Mobile TV services based on content distribution networks, in the process of migrating to 3GPP-MBMS (Multimedia Broadcast/Multicast Services). MBMS [9] is a 3G subsystem which provides point to multipoint downlink bearer service for IP packets in the packet switched domain. MBMS uses existing common channels, such as FACH, and relies in IETF multicast in the core network, minimizing impact on standards and infrastructure. MBMS supports two modes, broadcast (no billing/user activation) and multicast (billing, multicast join). Although 3GPP-MBMS provides a complete platform that addresses all issues related to Multimedia Multicasting, it is limited by the radio FACH channel to a 384kbps radio bearer; furthermore, MBMS applications must follow very strict API's. Besides 3GPP-MBMS, the DVB consortium has also standardized Multimedia streaming over IP Multicast [10]. In the DVB use-case, a very interesting limitation exists: the channel is unidirectional, requiring an additional channel for signaling (which might not always be available). In the DVB consortium, group security can be achieved using off line mechanisms such as smart cards, and QoS relies heavily on FEC algorithms. These solutions intend to overcome the lack of a reliable return channel, and do so to the expense of a limited set of services and lack of user interactivity (considered a requirement in NGN). Nonetheless DVB is an industry standard with commercially deployed solutions over the world, thanks to its broadband capabilities that easily overcome the overhead created by the FEC headers necessary to deliver multimedia with good QoS. III. IP UNICAST/MULTICAST TO L2 MAPPING The after birth split of IP Multicast from IP Unicast can be considered decisive for much of the problems previously presented. In IP Unicast, messages are delivered to a well defined receiver (represented by an IP address) while IP Multicast is delivered to a well defined group (also represented by an IP address) dynamically defined over time. Broadcast can be considered a special case of multicast where all nodes belong to a group of all nodes. In the most common communication scenario, Unicast appears as function in which a sender pushes a message to a single receiver. This then leads to a mapping at L2 level of these addresses (as defined for instance for IPv6 in RFC 2464 [11]). But for Multicast/Broadcast the communication is no longer a simple function, as to one original message correspond several receivers - more than one node can receive the same message sent by a single sender. Therefore IP routing is separated into two complete operations: Unicast communications, which is a one-to-one function of the source and destination, and Multicast/Broadcast which is a one-tomany relationship. A. Technological Considerations It is therefore understandable the different implementation strategies for IP Unicast and Multicast/Broadcast. For instance, in switched environments, unicast packets are forwarded to a single node (the receiver), broadcast packets are forwarded to all nodes and multicast packets should be forwarded only to the interested nodes. Unfortunately this is not usually how things work; e.g. most of today’s Ethernet switches do not support the necessary functionalities to avoid sending multicast traffic to all ports. The switch needs to support IGMP/MLD snooping in order to correctly forward multicast packets, but this extra logic increases costs, and as such it is usually a dropped functionality by vendors. But the largest hurdles with multicast are not in switched environments. In shared mediums such as the popular 802.11, where every node listens to the medium and filters its own frames, the difference between multicast and broadcast at the layer 2 level blurs to a point where they are undissociated. The 802.11 MAC handles packet losses, but only for unicast transmissions; in broadcast/multicast neither acknowledgments nor retransmissions occur [13] since no receiver or flow control exist. Furthermore, Broadcast/Multicast transmissions in wireless environments require that the frames transmitted much reach all nodes in the maximum radius of the sender. The consequence is the need to transmit at maximum power, with implications on the transmission ratio. This means that, for example in the case of 802.11b, broadcast/multicast frames are sent at the base rate (for 802.11b this means only 1Mbps of the theoretical 11Mbps available) without any reliability mechanisms provided either by the IP or MAC layer. Considering that Next Generation Networks (NGN) aim to provide always best connected services, meaning that the same service will be made available in a heterogeneous network composed of several technologies with very different mechanisms for the transmission of Multicast packets, offering a High Definition MultiMedia (HDMM) stream with reasonably high rates in such an environment suddenly becomes very challenging. As an example lets consider a NGN operating a IPv6-based network (a normal assumption in NGN) consisting of DVB, 3GPP-MBMS and WiFi, where a HD multimedia stream is being distributed through Multicast (it would be very expensive to distribute the stream over unicast in a network with a unidirectional DVB link), an example being developed in the IST project DAIDALOS [14]. Figure 2 represents in a very simplified manner this heterogeneous network, including the border routers, the QoS Broker (manager of QoS aspects) and the A4C server (authentication, authorization, accounting, auditing and charging) [14]. The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07) Any user equipment (UE) in the DVB network shouldn’t have any QoS problems receiving the flow, as the DVB channel provides more than enough resources for the HDMM stream. Unfortunately the same does not hold true for the 3GPPMBMS network where the channel used to send Multicast traffic has a 384kbps bandwidth. For the WiFi network the same problem appears as Multicast is sent using broadcast frames which are sent at the base rate (in the 802.11b case this means 1Mbps). The operator could request from the content provider three different multimedia streams for each of its networks, but that would mean increased exploitation costs. Another option would be for the operator to adapt the content to each of its networks using Content Adaptation Networks (CAN's), which is also a quite expensive solution. IP Access Router Radio Gateway TD-CDMA IP IP IP 802.11 IP Wifi Access Point Diameter Access Router COPS Content Provider COPS SPP Diameter Mobile Terminal DVB Diameter A4C QoS Broker IP COPS DVB-S Encapsulator Broadcast Access Router Figure 1 – Simplified view of an NGN architecture. B. Dynamic mapping proposal Interesting enough, all the above technologies, should a unicast stream have been used, would have been able to deliver up to 14.4Mbps in the 3G network (considering HSDPA) and 11Mbps (considering 802.11b). Therefore it is apparent that motivation exists for the case of the transmission of IP multicast packets over unicast L2 links in such a way that the optimum channel is used. In the aforementioned scenario the operator would have been able to deliver the HDMM stream to its users with the best available QoS as long as the last hop could have relied in a Unicast Channel with adequate power control and retransmissions mechanisms provided by the underlying unicast layers. Nevertheless, in usage cases where several UE are listening to the same HDMM stream, the use of several unicast channels could lead to an early starvation of resources, thus breaking the all Multicast/Broadcast concept of resources optimization through sharing mechanisms. The solution to these conflicting requirement is fortunately minimally intrusive, as the only modification required to the network is that the mapping done between IP and Layer 2 is not staticall but instead relies in a dynamic algorithm capable of choosing when is it worth forwarding packets in Unicast or Multicast/Broadcast mode, and selecting the best (technology-dependent) layer 2 channel. This concept is schematically presented in Figure 2. IP Unicast Multicast/Broadcast Mapping Unicast Multicast Broadcast L2 Technology Figure 2 – Dynamic mapping concept. C. L3/L2 Switching Control In our proposal, multicast routers support a dynamic mapping between IP Multicast groups and L2 Unicast/Multicast/Broadcast. The mapping must be controlled by an algorithm that should not only take into consideration the number of listeners, put also the transmission power requirements, the necessary bandwidth, subscribers profile and subscribers feedback. For NGN, this algorithm could be as complex as required, incorporating operator policies, and being a function of the technology features related with unicast vs broadcast channel usage. For scalability and efficiency, dense listener environments would usually map IP multicast into the standard Multicast/Broadcast channels. Nonetheless this sparse/dense threshold must be further evaluated, being not only technology dependent, but also dependent on current traffic flows and user-profiles. This dynamic mapping aims to optimize the provisioning of HDMM services. As such, QoS requirements of this multicast stream should be considered by the algorithm, and the network measurements associated should impact the algorithm. Although several work in the area of QoS measurements in IP Multicast environments exist [15], none addresses the specificity of our approach, as they center themselves in an end-to-end problem while we here intend to work only in the last hop - where bottlenecks usually resides. For heterogeneous environments, we require a media independent protocol capable of feeding network level reports to the default router. For multimedia applications, RTCP [16], seems quite appropriate (albeit coupled to RTP), but would become an superfluous protocol for any other application. On the other hand, group management protocols such as MLDv2 (IPv6) cannot be avoided. The MLDv2 protocol is used to periodically signal listeners and routers subscription information. We therefore defined extensions to the MLDv2 protocol, integrating extra information on the reception quality of each user. An MLDv2 extension is an appropriate choice since this is a scalable protocol independent of the transport layers, and can provide agnostic QoS information. The «The Auxiliary Data field» of the «Multicast Address Record» (Section 5.2.10. of [16]) is used to incorporate information such as time since last MLD message (Time Delta), packets received in the last period (since previous MLD report) and inter-arrival jitter (see Figure 3). The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07) PC 1 Streaming server WiFi access router PC 2 Figure 3 - Proposed MLDv2 QoS Extension Since MLDv2 messages are periodic, the multicast router can evaluate its listeners data through the QoS Extension. This enables the router to make approximate calculations on the QoS of each and every authorized receiver. The results can then be included in the decision algorithm. Based on this information, the operator can thus implement algorithms that are able to trade service quality and power efficiency to a given user (using a unicast L2 bearer) by resource efficiency to multiple users (using a broadcast bearer), without changing its IP multicast service provision infrastructure nor incurring intrusive signaling at the core control plane. Besides the increased QoS provided by the use of a Unicast Channel, the use of a L2 Unicast channel can also assist the operator in terms of security. At the L2 level, this avoids the group security problems, replacing it by a more common point-to-point security problem, easier to handle by security experts. IV. PROTOTYPE EVALUATION In order to evaluate the feasibility of our proposal a prototype was developed. The test network was made of several Linux boxes, implementing a streaming server, a multicast router (running our software) and several terminals accessing the network via WiFi (Figure 4). WiFi (802.11b) has a specific multicast channel, and thus the software was developed for exploiting this channel. Note that the situation with (e.g.) WCDMA environments would be similar, but with other technology specific broadcast bearers. The software developed consisted of a modified version of MRD6 [17], to which we further added a listener’s database, a conditional forwarder and a basic algorithm that controlled the conditional forwarder. In more advanced environments, this algorithm would be configured by a policy mechanism, but in our case was hard coded. The prototype code is available to public scrutiny under the MRD6 GPL license. Note that the client application software is unmodified, and the operation of our dynamic switching mechanism is not perceived by the terminals. The only change on the client software is the MLDv2 messages, which can be skipped, if no QoS control is being considered. The tests conducted in this platform consisted of sending 1Mbps IPv6 Multicast flows from the streaming server to a variable number of terminals using both VLC [18] and mgen4.2b6 [19]. PC 3 Figure 4 – Prototype evaluation test bed. VLC was used to analyze the behavior of the dynamic mapping and (with the exception of problems associated with packet loss, described below), VLC does not perceive any change on communication when dynamic switching is performed (changing between the L2 multicast channel and the unicast channel of WiFi). The mgen stream test lasts 10 seconds and is rebroadcasted every 20 seconds. In the 10 seconds window between the end of a stream and the beginning of the next, a new terminal joins the multicast group. The IP multicast listener Join message triggers the dynamic mapping control algorithm (a very simple algorithm was used): bool mc2un_base::is_it_broadcast (const inet6_addr &grp) { if (flows active on broadcast == 0 ) AND (current flow bandwidth < TECH_LIMIT) if(listeners.count(grp)>=THRESHOLD) { return true; } return false; } Future work will consider improvements to the algorithm taking into consideration IP and MAC layer measurements, as well as operator policies, and QoS requirements. Nevertheless, for concept demonstration purposes, this algorithm is adequate. The results of the tests are presented in Figure 5 and Figure 6. Although only one test run is shown, the results were not statistically different between the multiple test runs that were done. The figures start to show the 1Mbps IP multicast stream as received by the first of the listeners. Being the first listener the router algorithm decides that it should receive the IP multicast flow over a L2 Unicast link. As such the available channel bandwidth and L2 mechanisms (such as retransmissions) provide a reliable link for the delivery of the IP multicast stream. As soon as a new listener joins the group (at 20 s), the algorithm opts for optimizing access resources and switches the mapping to the standard Multicast/Broadcast channel which transmits at the base rate of 1Mpbs, using therefore the maximum capabilities of the technology. In our physical scenario packet drops occur at a 20% rate, which The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07) without any recover mechanism (such as FEC or retransmissions) can be considered a normal value considering that 10% are accounted by overhead of the LLC, 802.11 and PLCP headers (this overhead exceeds the available bandwidth on the multicast bearer). By (dynamically) binding IP Multicast to several L2 Unicast channels in a sparse listener environment, the operator is able to deliver IP multicast contents with better QoS and Security mechanisms supported by L2 intrinsic mechanisms, and optimize its access network resources. Note that Next Generations Networks are expected to provide users with large set of available services using technologies with increasingly small radio cells. This may lead to situation where IP multicast services may be popular in the network, but nevertheless will have sparse listener environments in many cells, a scenario in which our approach greatly improves QoS and security. Future work will focus in enhanced algorithms that can adapt to each technology and in further analysis of the efficiency threshold of IP Unicast/Multicast communications in heterogeneous networks. REFERENCES [1] Figure 5 – Packet rate of a multicast stream over a WiFi unicast channel and multicast channel. [2] [3] [4] [5] [6] [7] [8] [9] Figure 6 – Packet Inter arrival of a multicast stream over a WiFi unicast channel and multicast channel [10] [11] The second figure shows the different behavior of the Multicast/Broadcast channel (versus the unicast channel) – although similar, the multicast has a dispersion of inter arrival times consistently shifted upwards several miliseconds. This behavior is different of the unicast transmission, where retransmission mechanisms in L2 play an important role in recovering from packet loss, shown by inter arrival times of less than the base 10ms, meaning that retransmitted packets where sent meanwhile. V. CONCLUSION We have proposed an architecture for dynamic binding between IP multicast and L2 Unicast and Multicast/Broadcast bearers. This binding has so far has been considered static, which limits the usage of IP multicast in several scenarios in which a dynamic bidding could improve QoS and security aspects. [12] [13] [14] [15] [16] [17] [18] [19] S. Deering; RFC1112, “Host extensions for IP multicasting”; August 1989 Dapeng Wu, et al; Streaming video over the Internet: approaches and directions”; Circuits and Systems for Video Technology, IEEE Transactions on; Volume 11, Issue 3, March 2001 Page(s):282 - 300 Imai, Y., et al; “XCAST6: eXplicit multicast on Ipv6”; Proceedings. 2003 Symposium on Applications and the Internet Workshops, 2003; 27-31 Jan. 2003 Page(s):238 - 243 Chawathe, Y, et al; “RMX: reliable multicast for heterogeneous networks”; INFOCOM2000, 2000; March 2000, Page(s): 795-804 vol.2 V Roca, et al; “Design of a multicast file transfer tool on top of ALC”; Computers and Communications, 2002. Proceedings. ISCC 2002, 2002 Satou, H.; “Authentication, Authorization and Accounting Framework for Multicast Content Delivery”; Communications, 2005 Asia-Pacific Conference on 03-05 Oct. 2005 Page(s):630 - 634 Y. Chawathe, “Scattercast: An architecture for Internet broadcast distribution as an infrastructure service,” Ph.D. dissertation, Univ. California, Berkeley, CA, Fall 2000. J. Jannotti, et al, “Overcast: Reliable multicasting with an overlay network,” in Proc. 4th Symp. Operating System Design and Implementation (OSDI), Oct. 2000. Boni, A., et al, “Multimedia broadcast multicast service - technology overview and service aspects” in 3G Mobile Communication Technologies, 2004. 3G 2004. Fifth IEE International Conference on, 2004 Page(s):634 - 638 ETSI, “Specification for the Transmission of Data in DVB Bitstreams,” TS/EN 301 192. M. Crawford, “Transmission of IPv6 Packets over Ethernet Networks”; IETF RFC 2464, December 1998. D. Pendarakis, et al, “ALMI: An application level multicast infrastructure,” in Proc. 3rd Usenix Symp. Internet Technologies & Systems (USITS), Mar. 2001. ANSI/IEEE Std 802.11, “Wireless LAN MAC and PHY Specifications,” 1999. R. Aguiar et al, “Daidalos: The Operators Vision of the Next Generation Internet”, INFOCOM 2006, April 2006. Bin Wang, et al; "Multicast routing and its QoS extension: problems, algorithms, and protocols"; Network, IEEE, Volume 14, Issue 1, Jan.Feb. 2000 Page(s):22 – 36 H. Schulzrinne; "RTP: A Transport Protocol for Real-Time Applications"; IETF RFC 1889; January 1996 MRD6 - URL: http://hng.av.it.pt/mrd6/. Videolan - URL: http://www. videolan. Org MGEN tool- URL: http://manimac. itd. nrl. navy. mil