Multicast Routing Protocols in a Satellite Environment*

Transcription

1 Multicast Routing Protocols in a Satellite Environment* Nikhil Ninan and Godred Fairhurst Electronics Research Group, Department Of Engineering Aberdeen University, Scotland, AB24 3UE {nikhil, erg.abdn.ac.uk Abstract- This paper discusses the Protocol Independent Multicast () [1] multicast routing protocol. It examines the issues that arise from the use of in a satellite network. The main focus of investigation is the control overhead on the return channel of a bi-directional satellite link and possible methods for reducing this overhead. The paper shows that can be implemented in a satellite network with the default configuration settings but performance can be optimised by tuning specific parameters. A long-term solution with interoperability in different two-way satellite networks will require a proxy at the satellite terminals to interact with the control plane used to build/maintain multicast trees. I.INTRODUCTION Multicast communication is the ability of a network to accept a single message from an application and to deliver copies of it to multiple recipients at different locations in the network; where the network controls the replication, so that the packets are not sent to parts of the network where there are no listeners, thereby minimizing bandwidth consumption. Multicast-capable routers perform the replication and forwarding; they construct a delivery tree with a multicast routing protocol. Protocol Independent Multicast Sparse Mode (-SM) [1] is a multicast routing protocol, it has become the dominant routing protocol in the general Internet since 2003 [2]. While much of the focus on multicast research continues to be on addressing the challenges of the traditional Internet, other non-traditional infrastructures, such as satellite and wireless networks are beginning to be recognized as important environments in which to investigate the provision of multicast communication. The inherent broadcast nature of these networks suggests that multicast might be easier to provide in these networks compared to the traditional Internet. Recently, commercial vendors have been able to offer some types of multicast services more efficiently over a customer s satellite networks [3]. Satellite networks are becoming important for worldwide communication. They not only provide global coverage, but they are also capable of consistently sustaining high bandwidth levels, for mobile and moving users. For geostationary orbit satellites, the transmission from the source to recipients can be accomplished in a single hop. Currently, two thirds of the world still does not have a wired network infrastructure [4]. Satellites are also ideally suited for delivery of multimedia multicast applications. Since the Internet protocols have been designed without taking into account the inherent characteristics of the physical support, the harmonious and the efficient integration of the satellite systems, research is required to address the multicast routing and media (audio and video) distribution issues over satellites. One scenario in which satellites have an undisputed advantage is for mobile communications (i.e. where the terminal is used on the move or set up and used where there is no terrestrial network available). II.THE BGAN SYSTEM The Inmarsat Broadband Global Area Network (BGAN) system supports point to point telecommunication services on portable and semi fixed land mobile platforms with low to medium gain non-tracking antennas providing bit rates in the range 216 Kbps to 432 Kbps in downlink, and 72 Kbps to 432 Kbps in uplink, depending on type of terminal. The BGAN air interface was optimised for a land-portable environment with directional antennas [5]. A. BGAN Service extension to Multicast The BGAN baseline system has been specified for point-topoint satellite-based UMTS (Universal Mobile Telecommunications System) services to individual terminals. Satellites offer a resource-efficient means of multi-casting over wide areas. This paper investigates suitable protocol optimisations to provide efficient multicast services using the BGAN system. The BGAN multicast service extensions will allow point-topoint transmission of multimedia data (e.g. text, audio, picture, video) from a single source point to an multicast group in a multicast service area. The source may be located outside the BGAN domain (e.g. multicast source located * This work is funded as part of the BGAN Service extension to Multicast by Inmarsat Ltd.

2 somewhere in the Internet), behind a BGAN Mobile Terminal (MT) or be internal to a BGAN Service Provider domain. A high level overview of the BGAN Service Provider is shown in Fig. 1. The BGAN multicast service is intended to efficiently use satellite/network resources. Data is transmitted in the BGAN multicast service area as defined by the BGAN Service Provider. The BGAN satellite operator will be able to selectively transmit to beams within the BGAN multicast service area that contain members of a BGAN multicast group. B. The Protocol Protocol Independent Multicast () is the most widely deployed protocol for intra-domain multicast routing. The protocol maintains neighbouring with other enabled routers by exchanging Hello messages between them at regular intervals. The Designated Router (DR) on the Receiver s side and Source s side communicate with the Rendezvous Point (RP) using messages; to deliver multicast content between them. Internet Group Management Protocol (IGMP) is used between the end host and Receiver s DR to source multicast content. Fig. 2 shows the message sequence involved in the receiving and transmitting of multicast content. messages control the multicast flows; Join messages are sent periodically upstream towards the RP. Receiver Receiver Router (DR) Router (RP) Source Router (DR) Source Fig. 1. Overview of BGAN multicast network. Before a BGAN Mobile Terminal (MT) is allowed to join a BGAN multicast group it will need a valid BGAN multicast subscription as well as being located inside the BGAN multicast service area. The provision of a BGAN multicast service subscription to a BGAN MT will be performed by the BGAN Service provider, either at the request of a user or a third party on the user s behalf (e.g. corporate subscription). It is assumed that one or more Terminal Equipment (TEs), for instance laptops, may be connected to a single MT. The BGAN Core Network will be responsible for establishing BGAN resources to transport the multicast data, and this will be done either prior to the start of the multicast data transfer or upon presentation of the multicast data to the BGAN system. Due to high demand on spectrum anticipated in a fully matured BGAN system, it is vital that spectrum efficient technologies be introduced into the system design where feasible, especially for the return link resulting at an MT (where spectrum has to be pre-allocated to individual MTs). Key areas that may be tuned for the return link are a reduction in traffic volume, and a reduction in the number of transmissions required (particularly in the case where terminals are not transmitting other data, and could otherwise be passive, conserving power and eliminating the corresponding channel signalling). IGMP-Report for Groups DR updates TIB, Multicast data IGMP Query to LAN CHECKS Unicast -Register IGMP-Report receiver responds RP updates TIB -Register STOP Source DR stops (*, G) -Join registering for a while DR waits for a RP updates TIB -Join (S, G) -Join Source DR forwards multicast flow via the RP Receiver Router discovers Source Address (S, G) -Join Source DR forwards multicast flow via the RP Source DR forwards multicast flow directly to the Receiver Router -Prune C. Network Topologies -Prune Fig. 2. Message Sequence. The focus of this research is to investigate the issues that may arise from the deployment of the multicast routing protocol over a satellite network and to finally propose a proxy that can implemented in two-way satellite networks. To investigate the control overhead involved in receiving and transmitting multicast content, the network topology can be classified into the following: 1) Receiving multicast content: One or more MTs in the same spot beam: In this case, there exists multiple Mobile Terminals (MTs) receiving multicast content simultaneously under the same spot beam. Each of these MTs will have a single Terminal Equipment (TE) receiving multicast content from one or more multicast groups.

3 One or More TEs connected to a single MT: In this case, multiple Terminal Equipments are connected to a single MT or a LAN connected to the MT. The MT will have one or more multicast enabled routers connected to its ports and receiving multicast content from multiple multicast groups simultaneously. 2) Transmitting multicast content: When a source is connected to the MT directly or via a LAN connected to a MT; the scenarios for testing does not get affected. This is because the source s DR encapsulates the multicast packets into register messages and unicasts them to the RP. If there is more than one source beyond an MT, then the DR will send two unicast streams of Register messages to the RP. V. MULTICAST ROUTING PROTOCOLS In the early days of multicast, multicast routing was performed by multicast-capable, virtual network running on top of the internet called the Multicast backbone (MBone) [6]. The MBone used Distance Vector Multicast Routing Protocol (DVMRP) [7] or Multicast Extensions for Open Shortest Path First Protocol (MOSPF) [8] to route multicast traffic. DVMRP and MOSPF depended on the features of underlying point-to-point (unicast) routing protocols. To remove this dependency and to develop point-to-multipoint (multicast) routing protocols that operate in a hierarchical manner with subnet multicast routing protocols led to the development of multicast routing protocols that used tree construction mechanisms. The existing tree-based routing protocols can be classified into source-tree based and center-based trees. The sourcebased trees produce a source-rooted tree with low delay but for applications with multiple senders, the management overheads for routing tables and resource reservations are too high. On the other hand center-based trees are easy to implement and manage, but configuration of candidate center nodes is required and the optimization nature of such as tree cost and delay is not considered. has a dense mode version as well as a sparse mode version. The sparse mode version is better suited for networks where the receivers are spread around a wide area while dense mode is ideal where the receivers are densely populated [9]. The issues involved with the deployment of IGMP, DVMRP and -SM over a satellite network as been discussed in [11]. Reference [12] considers the end-to-end delay, network resource usage, traffic concentration for source-based trees and center-based trees plus overhead traffic, scalability, and joins time for network models running the dense mode of [13], the sparse mode of and Core-Based Trees (CBT) protocol. This gives a clear indication that sparse mode is the best suited multicast routing protocol for deployment in a satellite network. VI. ROUTING OVERHEAD Initial testing has shown that does work over a satellite link in conditions of delay, error and packet loss. However, the control overhead on the return channel is significant; this led to the further investigation of control overhead. The forward channel is ideal for multicast because a large global coverage beam can be used to transmit data to a number of receiving MTs while on the other hand the return channel is very expensive. This is because bandwidth on the return is allocated only on request; the MTs have to wait for their allocated time slot before they can transmit data. This makes the reduction of control overhead on the return channel a very important issue. messages are encapsulated in packets (as shown in Fig. 3); therefore for the calculation of control overhead, the header must also be taken into consideration. Taking the above mentioned network topologies into consideration, tests were performed for a situation where 100 Mobile Terminals would be sourcing multicast content from none to 10 multicast groups simultaneously, where each group had a single source located beyond the satellite link (i.e. in the corenetwork or Internet). Host Application IGMP Mobile Terminal Host Application IGMP Source/ Group IGMP Fig. 3. The protocol stack. Source/ Group IGM P BGAN Multicast Service Node -SM -SM Proxy NAS Proxy NAS A. Overhead Scenarios for receiving multicast 1) MTs not receiving or sending any multicast content: Multicast routers with enabled on its interface sends Hello messages on all its interfaces at regular intervals of time. The default setting is to send Hello messages every 30 seconds. If an MT is not sourcing or sending multicast content, due to specification [1], it has to refresh its state

4 with neighbouring routers. This would lead to the customer paying for their MT to maintain states with its neighbours. 2) MT receiving multicast content: For receiving multicast content for a particular multicast group, the Designated Router of the interested receiver(s) has to send Join messages to the RP. These messages have to be sent at regular intervals, towards the RP to maintain the state within the routers. As the routers maintain state on a {group, source} basis, Join messages have to be sent separately for each pair, at regular intervals. Fig. 4 shows the overhead for in its default implementation to be the highest. The overhead increases linearly as the number of groups being received and the number of receiving MTs increases. For the same test scenario, if IGMPv3 were to be used the decrease in control overhead is 85% (as shown is Fig. 4). This is a very significant reduction. In the multicast mechanism, IGMP is used between end hosts and last hop routers and multicast routing protocols are used between multicast routers in backbone networks. Currently, it has become common for customer premises to contain a single host or a LAN with a single segment, and therefore, most ISPs use IGMP as the interface between the customer premises and themselves. This is because IGMP is not a router communication protocol but is a group membership protocol used for communication between routers and TEs. Advanced customers have LANs with multiple segments and perform their own multicast delivery within LAN. For these customers, it is impossible to use IGMP at the ISP and customer boundary. Therefore IGMPv3 is no longer the preferred option as a last hop solution between two multicast routed networks [6]. In the past, some ISPs have provided multicast information delivery services. On the other hand, from the standpoint of ISPs, it is inconvenient to introduce different kinds of protocols, IGMP and multiple kinds of multicast routing protocols. Hence IGMP is not the option that customers and vendors want. 3) MT sending multicast content: When a source starts transmitting multicast content, the source s DR encapsulates the multicast packets with a Register message header and unicasts the message to the RP of the multicast domain. A Register message consists of a 20Byte header, an 8Byte header followed by the payload; the payload is the maximum amount of the multicast content (depending on the MTU) that can be sent in a single packet on the link. If there are interested receivers for the group, the Register messages are de-capsulated and forwarded to the receivers as multicast packets, by the RP and the RP also sends a Register- Stop message to the source s DR. If there are no interested receivers, the RP immediately sends a Register-Stop message to the source s DR. The source s DR will refresh the state with the RP periodically using a Null-Register Message [1]. The Null-Register Messages will have no payload, i.e. it consists only of the header and the Register header. In a situation where the source is connected to the MT or on a LAN connected to the MT and there are no interested receivers, unnecessary multicast content will be sent over the satellite return channel until the RP sends a Register Stop message to the source s DR. For the case of a source transmitting at 492Kbps (Class-I, Inmarsat Mobile Terminal), in the worst-case scenario (1.6 seconds RTT), the amount of data sent on the uplink of the satellite network will be very high. In the case of terrestrial networks this is not an issue due to the usage of resources in minimal but on the return channel of a satellite link this is very expensive. The customer will have to pay for bandwidth used even if there were no receivers at the time of transmission. B. Methods for reduction of control overhead 1) Aggregation of Join/Prune Messages: The specification does not specify a definite rule for the aggregation of Join/Prune Messages, only a couple of exceptions. The first exception is that if there is a (*, G) Join entry for a particular group, the same Join message must include a (S, G, rpt) Prune source list entry for every source the router does not want to receive for the particular group. The second exception is that, a single Join message can contain a maximum of 255 group entries and any fragmentation done must comply with the first exception. The default implementation maintains timers for each group within the router state and sends Join/Prune messages periodically, to refresh state timers within upstream routers.

5 Further investigation has to be carried out for timer values against the amount of unwanted traffic to find the ideal value for the timers. This will involve detailed analysis of overhead reduction to the unnecessary usage of available bandwidth, i.e. if the period before pruning multicast content is too long, unwanted data will still be transmitted over the satellite link. Fig. 4. Comparison of control overhead on the return channel [Lower-plane: IGMP overhead, Middle-plane: - SM overhead when aggregated, Upper-plane: -SM overhead in default settings]. When a set of Join messages were aggregated to form a single -SM message before being sent, there was a 52% reduction in the overhead on the return channel; this is a very significant reduction and the aggregated implementation is still within the specification. 2) Configuring Timer settings: As mentioned earlier protocol uses periodic state refresh to maintain state between its neighbours. The periodicity of these messages can be lowered by changing the timer values within the implementation; thereby reducing the overhead on the return channel. Multicast routers with enabled on its interface sends Hello messages on all its interfaces at regular intervals of time. The default setting is to send Hello messages every 30 seconds; with an overhead of 54Bytes/message. This becomes extremely important due to the fact that Hello messages need to be exchanged between neighbours, even if no multicast content is being received or transmitted. If this is changed so that Hello messages are exchanged only once every minute, the reduction of overhead is a further 9% to that when Join/Prune messages were aggregated. And if it is increased further to send only once every two minutes the reduction would be a further 4%. Therefore, by reducing the frequency of messages overhead can be reduced but too high a value could lead to unnecessary traffic being over the satellite link towards the MT. 3) Snooping the BGAN control plane: The Mobile Terminals has to connect to the Core Network through the BGAN control plane to establish a connection based on parameters that could be company specific or service specific, i.e. the rate of transmission, delay, QoS, etc. This gives another option for eliminating the Hello message over the return channel of the satellite link. The BGAN control signals could be spoofed to establish connection parameters (i.e. state refresh timers) instead of exchanging Hello messages over the satellite link. The possible implementation of this solution into the proxy has to be investigated in detail. The use of the BGAN control signals will be ideal as far as receiving multicast content is considered but when multicast content is to be sourced from beyond the MT; this will lead to loss of first few multicast packets, i.e. atleast the first RTT s of data traffic. 4) Use of Null Register Messages: defines the concept of a Null-Register message (section 4. A. 3). Since the Null- Register message does not contain any multicast content; the usage of Null-Register messages instead of the encapsulated Register message will reduce the overhead on the return channel significantly. The use of Null Register messages would also reduce the processing performed by the RP and the usage of network resources is also reduced. The use of Null Register messages for initial registering of the source with the RP will lead to the loss of the first few multicast packets being transmitted by the source. A longer delay is also expected before which multicast content will be received. The impact of this loss is expected to minimal and it is expected that the application will be able to function even with this loss and delay. The use of Null Register Messages and proxying of Hello messages using the BGAN control plane might have to be service-level decisions. Customers will have the option of deciding on the level of service they require on a connectionby-connection basis, i.e. if they were to multicast content that required immediate availability and no loss of initial packets they would opt for the expensive option. So register messages would be sent as encapsulated multicast content.

6 VII. FUTURE WORK Investigation of the usage of Null-Register messages will have to be performed and impact on the end system has to be carried out. This is due to the fact that if an interested receiver does exist when a source starts transmitting, the RP directly forwards the de-capsulated Register message payload to the receiver. This will even lead to the loss of the first RTT s (Round Trip Time) of data packets. The use of Null-Register packets has not been discussed in the specification [1] during the initial registration phase. Investigation of the different implementations, with regard to this issue, has to be performed to understand its impact. The main issue with this possible solution is that it is not compliant with the specification, which might lead to investigation of a possible acknowledgement mechanism for Register messages. The main focus of this research is to propose a configuration or proxy that could be implemented in the BGAN satellite network. Some of the possible options suggested in this paper for the reduction of overhead is BGAN specific; this will make the investigation of interoperability of the proxy in other two-way satellite networks (like DVB-RCS (Digital Video Broadcast-Return Channel Satellite)), an important area of research. The placement of Rendezvous Point and the network topology are important issues that have to be taken into consideration when looking into other two-way satellite systems. VIII. CONCLUSION This paper has discussed the issues that arise with the implementation of multicast routing protocol in a satellite network. The main focus has been on the reduction of control overhead on the return channel of the satellite link. Results from the initial investigation show that does work over a satellite link (e.g. Inmarsat) but not efficiently. The overhead on the return channel is very high and this needs to be reduced. A few possible solutions for the reduction of the control overhead on the return channel have been suggested and the results for a few have been discussed. The paper shows that can be implemented in a satellite network with the default configuration settings but performance can be optimised by tuning specific parameters. A long-term solution with interoperability in different twoway satellite networks will require a proxy at the satellite terminals to interact with the control plane used to build/maintain multicast trees. REFERENCES [1] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, Protocol Independent Multicast - Sparse Mode (- SM): Protocol Specification (Revised), IETF Internet Draft, draft-ietf-pim-sm-v2-new-12.txt, September [2] S. Deering, D. L. Estrin, D. Farinacci, V. Jacobson, C-G. Liu, L. Wei, The Architecture for Wide-Area Multicast Routing, IEEE/ACM Transactions on Networking, vol. 4, No. 2, April [3] K. C. Almeroth, Y. Zhang, Using Satellite Links as Delivery Paths in the Multicast Backbone (MBone), HRL Laboratories, October [4] E. Ekici, I. F. Akyildiz, M. D. Bender, A Multicast Routing Algorithm for LEO Satellite Networks, IEEE/ACM Transactions on Networking, Vol. 10, No. 2, April [5] M. Vilaca, The Inmarsat 4 and BGAN Systems: Services, Capabilities and Capacity, Inmarsat. [6] H. Eriksson, MBone: The Multicast Backbone, Communications of the ACM, Vol. 37, No. 8, pp 54-60, August [7] D. Waitzman, C. Partridge, and S. Deering, Distance Vector Multicast Routing Protocol, RFC 1075, November [8] J. Moy, Multicast Extensions for OSPF, RFC 1584, March [9] L. Wei, D. Estrin, Multicast Routing in Dense and Sparse Mode: Simulation Study of Tradeoffs and Dynamics, University of Southern California. [10]Y. P. Gong, T. Kato, S. Itoh, Accommodation of - SM based multicast capable LAN in ISP using IGMP, Proceedings of the last international conference communication systems and networks, pp , [11]F. Filali, W. Dabbous, Issues on the Multicast Service Behaviour over the Next-Generation Satellite- Terrestrial Hybrid Networks, Proceedings of the Sixth IEEE Symposium on Computers and Communications, 2001 [12]T. Billhartz, J. B. Cain, E. Farrey-Goudreau, D. Fieg, S. Batsell, Performance and Resource Cost Comparisons for the CBT and Multicast Routing Protocols, Defence Advanced Research Projects Agency (DARPA), Naval Research Laboratory. [13]A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Dense Mode (-DM): Protocol Specification (Revised), RFC3973, January 2005.