IP conference routing optimisation over GEO satellites

Transcription

1 IP conference routing optimisation over GEO satellites H. Cruickshank, Z.Sun and L. Liang (University of Surrey, UK), A Sanchez (Telefonica R&D, Spain), C Miguel (SIRE, Spain), C. Tocci (Alenia Aerospazio, Italy) and B. Carro (University of Valladolid, Spain) H.Cruickshank@surrey.ac.uk ABSTRACT Satellites are also ideally suited for delivery of IP multimedia multicast applications such as conferencing. Therefore there is a need to address the multicast routing and media (audio and video) distribution issues over satellites. This paper describes the research results of a European IST project named IP ConferEncing with Broadband multimedia overgeostationary Satellites (ICEBERGS) on intra and inter domain multicast routing solutions for deployment over satellite to enable efficient multicast multiparty multimedia IP conferences. Scenarios of mixed unicast and multicast users are also presented. I. INTRODUCTION The complexities of deploying and operating wide scale terrestrial multicast networks can hinder the deployment, at least for the foreseeable near future. On the other hand, satellites are ideally suited for multicast real-time traffic. In order to reach efficient multicast for wide area coverage, next generation satellite systems will be required. The new emerging satellites with multiple spot beams and On-Board Processing (OBP) will have new capabilities of dynamically routing information between various spot beams. OBP improves support for real-time applications such as IP telephony and multiparty conference service. GEO satellites are the most suitable for multicast and large-scale conferencing, due to their wide area coverage and simple network management compared to MEO and LEO satellites. If the system can be optimised for multicasting real-time traffic, it would provide uniform continental delivery with a single satellite hop using only a small number of multicast enabled routers. The small number of routers should simplify deployment and operations/maintenance and also paves the way for introducing service level guarantees (an important requirement for a commercial service). Such a system would complement the next generation terrestrial infrastructure, which is expected to provide unicast service guarantees to those customers willing to pay for the service. To take advantage of its wide coverage and broadcast capabilities, a lot of efforts have been given to the integration of the satellite network into the existing Internet architecture. As one of the rapidly developed new Internet applications, multimedia multiparty IP conference appears its high demands of employing this integration service. To employ the multicast over an OBP satellite is highly desirable to overcome the expensive satellite bandwidth cost. II. INTRA AND INTER DOMAIN In this section, we will briefly summarise both intradomain and inter-domain multicast routing protocols whose adoption for the satellite multiparty conference system that was suggested by the ICEBERGS. In particular we will focus our interest on the so called near term solution for IPv4 intra-domain and inter-domain multicast routing, which seems to be a more suitable routing architecture for the deployment of multicast routing over the ICEBERGS network. As such this solution can be compatible with many existing systems and supported by many ISPs. This architecture consists of the following set of Internet protocols: The intra-domain protocol is assumed to be Protocol Independent Multicast-Sparse Mode (PIM-SM) [1], [5] ; each domain uses its own Rendezvous Point (RP) (one or more): a source located in a given domain registers with an RP of that domain; RPs belonging to different domains exchange information related to the existence of active sources by means of the Multicast Source Discovery Protocol (MSDP) [3] ; An extension of the classical unicast inter-domain routing protocol, BGP is used for inter-domain routing: Multiprotocol Border Gateway Protocol (MBGP) [2] [6]. MBGP cooperates with MSDP in order to provide efficient multicast tree construction between various domains. A. Intra-domain multicast routing deployment As far as intra-domain (within one domain) multicast forwarding is concerned, two deployment scenarios have to be analysed in order to properly frame this protocol in the ICEBERGS context: PIM-SM deployment over terrestrial networks only of ISPs that are not part of the satellite domain; PIM-SM deployment over both terrestrial networks of federated ISPs, and the satellite network ( we call them federated ISPs). Therefore, the following scenario may arises: PIM-SM procedures execution would be restricted in the multicast network domain of each federated ISP; such procedures would be carried out by the Designated Router (DR) interfacing terrestrial multicast sources/receivers of a given group G towards the RPs relevant to this group located in the ISP domain; this entails that each federated ISP will

2 autonomously manage its own RPs (no dependency on third-party RP), where group receivers will join the Rendezvous Point Tree (RPT), and group sources will join their own Shortest Path Tree (SPT). In the case of federated ISPs and within one ISP (ISP k ) network domain, there might many terrestrial unicast EU. The PIM-SM messages are carried out between each DR and the RP of the multicast group, which has been considered co-located with an SMR. In the frame of the multicast routing, we have only to take into account that PIM-SM sessions relevant to unicast EUs. This will take place between the Multicast Router (MR) located at ISP k Unicast-Multicast domain boundary and the RP of the multicast group. As far as satellite End Users (EU) are concerned, membership protocol (PIM-SM and IGMP: Internet Group Management protocol) would be executed either locally, if a multicast router is co-located with each satellite terminal (satellite enabled Multicast Router-SMR), or would be proxied to Network Operation Centre (NOC) if satellite terminals are not provided with an SMR. Concerning with PIM-SM, when an SMR is co-located with a satellite terminal, the relevant sessions should be accomplished between the SMR and a so called Satellite Rendezvous Point (SRP) located in the NOC, and PIM-SM sessions should be proxied to NOC as well (see Figure 1). The routing system adopted in the ICEBERGS network forces the adoption of an inter-domain routing scheme also between remote network domains of the same federated ISP, whenever such domains may be accessed by means satellite terminals. In this context, the use of anycast RP mechanism [4] to allow an arbitrary number of RPs per group in a single shared-tree PIM-SM is suggested. This way, each federated ISP domain may have its own RPs active for a given group, without forcing sources/receivers of the group to join a remote RP. It is recommended that all satellite enabled RPs should be located very close to the satellite terminals. Figure 1 shows the Multipoint Control Units (MCU). Terminals send multimedia streams to the MCUs by unicast, which collects the streams, manipulates and mixes them and generates conference multimedia flows. B. Inter-domain multicast routing deployment As far as MBGP is concerned, its deployment consists in a straight upgrading of the Exterior Gateway Protocol (), namely BGPv4, deployed in the frame of the ISPs confederation. This means that MBGP sessions should take place between each federated ISP domain and the satellite Autonomous System (AS) domain. Therefore BGP peers should be located both in the federated ISPs domains, and in the NOC where the Routing Arbiter (RA) of the confederation runs (Figure 2). As far as satellite EUs are concerned, since, they belong to the satellite AS domain, then the BGP co-located with the NOC will be in charge of advertising to the federated ASs reachability information for the networks the satellite EUs belong to. ISP k AS n Figure 1 ICEBERGS multicast and unicast hybrid routing architecture For what concerns the use of satellite communication resources, it is to be stressed that satellite multicast EUs requires a point-to-point bi-directional satellite traffic channel to the NOC, in order to carry out either only PIM- SM sessions, or both PIM-SM and IGMP sessions depending on the presence of an SMR at customer premises. This satellite traffic channels should be logically available, that is it should be automatically setup at terminal registration phase, and remain open as long as the satellite terminal is switched on. Whenever multicast signalling is going to be sent to the NOC, then physical resources should be required from the Traffic Resource Manager (TRM) on board, and released as soon as the signalling flow ends. For the case of EUs not provided with an SMR, the IGMP sessions will be exchanged with the SMR located in the NOC, while at customer premises only a unicast router would be required. IGP h BR h IGP h IGP h ISP h AS m RA BR K FES Sat. AS FES NOC BR MCS BR i ISP i AS p Figure 2 Star topology of the satellite inter-domain routing system Two Routing Information Bases (RIBs) will be populated into each BGP peer: 1. The Unicast Routing Information Bases (URIB), which contains unicast prefixes for unicast

3 forwarding, and which is populated with BGP unicast NLRI. 2. The Multicast Routing Information Bases (MRIB), which contains unicast prefixes for RPF checking, and which are populated with BGP multicast NLRI. We want to stress the fact that a point-to-point bidirectional satellite traffic channel should be made available between each satellite enabled BGP peer and the NOC BGP peer in order to properly carry out the MBGP sessions, as depicted in Figure 1. Without loss of generality, the satellite enabled BGP peer of the federated ISP domain has been made coincident with the SMR of the federated ISP multicast network domain. Concerning with MSDP deployment over the ICEBERGS network should take place by means of TCP connections between MSDP peers, which are likely to be congruent to the connections in the BGP routing system. Therefore, for each federated ISP MSDP peer and BGP speaker can be co-located in the same network node. Each federated ISP domain should be provided with (at least) a satellite enabled Multicast Router (SMR) which can also plays the role of RP in the context of the federated ISP domain. This RP may be either unique or can be one of a number of possible RPs available for a given group in the PIM-SM domain of the federated ISP, when anycast RP mechanism is implemented [4], thanks to this degree of freedom offered by the anycast RP mechanism. Without loss of generality we can consider co-located with the SMR of each federated ISP domain with both the functionality of RP (relevant to PIM-SM way of operation) and the functionalities of BGP/MSDP peers. This concept is also shown in Figure 1. Starting from this choice, we can conclude that both MBGP sessions and MSDP sessions may take place over the same point-to-point bi-directional satellite traffic channel. This channel is to be set-up at terminal start-up time between the satellite terminal of each SMR and the Fixed Earth Stations (FES) of the NOC. When we consider satellite EUs that have their PIM-SM RP proxied at NOC in the so called satellite RP (SRP), also their MSDP/BGP peer functionality proxied at NOC will be co-located with the SRP functionality. III. MEDIA MODELS FOR MULTIPARTY CONFERENCES The multiparty conference can be divided into two aspects: signalling and media. This section deals with media (such as audio and video) models only. There could be four media models [7] [8],[10] : 1. Full mesh: each participant sends his media data to all of the rest participants using unicast channels. Every participant manages the data streams he received. If the satellite network is employed, this model implies that each pair of users will occupy one satellite channel. Large bandwidth will be consumed in this model. 2. Multicast: In this model, every participant can use network multicast architecture for communications. It is ideally suited for large conference. However, all participants have to share a set of common codecs. 3. Centralized server: all participants send media data to only one conference server, at which the data are mixed if needed and redistributed to the participants. Latency is introduced by using the conference server and data redistribution. 4. Unicast receiver and multicast sender: This model combined the merits of the central server and multicast model. Regarding the media distribution, the first three models are not suitable for satellite because they either consume too much satellite bandwidth or introduce extra delay. Although the fourth model has some improvement to serve the multimedia conference, it doesn t add the satellite link into account. A new optimised model is proposed in the ICEBERGS project to integrate the satellite link with the terrestrial networks. With the support of multicast routing protocols, a conference model can be modified taking into consideration the impact of the satellite link on QoS provisioning. The most important issue is to avoid any media stream being delivered via more than one satellite hops because the typical delay introduced by one Geostationary satellite hop can be up to 280ms [9]. Therefore the conference model has to enable media delivery to their final multicast destinations via only one satellite hop. Another consideration is the trade off between the large bandwidth requirements of real-time multimedia conference and expensive satellite bandwidth cost. Rather than allowing every end user to directly communicate with the satellite, which also needs expensive end media mixing equipments, mixing a group of users data half way between the end users and the satellite is a better choice. One of the functions of a MultiPoint Control Unit (MCU) in the H.323 architecture [9] is acting as media servers. Multiple MCUs) Model, as shown (Figure 3), fits well both above satellite conference requirements. In this model, one or more MCU s exist on the network. Terminals (end users) send multimedia streams to MCUs by unicast, which collects the streams, manipulates them and generates multicast flows received by all terminals. This model minimizes the bandwidth in comparison to the unicast conference and simplifies the terminal requirements. The mixed satellite-terrestrial network and the relatively high satellite delay implies that it is not desirable to send unicast audio/video from one terminal to a remote MCU through a satellite and then receive the composite signal again through the satellite link. For this reason, several MCUs are needed, at least one in each corporate/business or ISP network. These MCU can communicate with each other using satellite multicast.

4 Multiprotocol Border Gateway Protocol (MBGP) and Multicast Source Discovery Protocol (MSDP) for a suitable multicast tree construction over the satellite network, as described in section II. This makes sure that the IP conference media is distributed efficiently over satellites. IV. CONCLUSIONS Figure 3 MCU Architecture Example In Figure 3, user A and B communicate with MCU1 by unicast and user C and D unicast their data to MCU2. The main reason we choose unicast instead of multicast between end users and MCUs is that each of the users participate in the same conference might receive different data. For example, the MCU stream towards user A must filter out user A own data, voice and video because user A is the source of this data. The more complicate example is that user A wants to see user B, while user B wants to see user C. Thus, the data send from MCU1 to user A and the data from MCU1 to user B will even more different. Multicast can not solve this problem unless user A and user B belong to different groups, which will make the multicast architecture much more complicate and suffer from the lack of the multicast addresses (especially in the IPv4 networks). Unicast technologies can easily satisfy the various demands of both user A and user B. Therefore unicast connection between each unicast end user and his local MCU are deloyed. We deploy multicast technologies between all of the MCUs to save the core network and the satellite bandwidth. In other words, we use satellite links to provide efficient multicast between various MCUs. Regarding scalability and compatibility, the multiple MCU model can also involve multicast end users. This kind of users has to be end-mixable equipments to handle the received media streams. It should work as an integration of one unicast end user and one MCU. All of the MCUs and multicast end users join the corresponding multicast conferences that interest any their local end users, which is itself for multicast user. Media streams are transmitted among these MCUs and multicast end users using the multicast routing solution of PIM- SM/MSDP/MBGP. A. Interactions between satellites and the media and signalling models For the satellite system to deploy multicast efficiently, there is a need to implement an efficient configuration of multicast routing protocols. Multicast routing is the underlying mechanisms for establishing multicast communications through the Internet. Therefore MCUs can be located close to the Rendezvous Point (RP) in Protocol Independent Multicast-Sparse Mode (PIM-SM) protocols (intra-domain), in the federated ISP domain. Also the satellite network is used efficiently to provide inter-domain routing by implementing satellite based This paper introduced a multicast solution to support multiparty multicast multimedia IP conference over next generation OBP GEO satellite. This solution consists of three multicast protocols: PIM-SM, MSDP and MBGP. To deploy this multicast solution, the three multicast protocols have to seamlessly cooperate with each other to realize both the intra-domain and inter-domain multicast. The PIM-SM is needed to enable multicast in the satellite domain and each ISP domain. It is also employed to construct the multicast tree between each domain and the satellite domain. The MBGP decides the shortest route to carry the MSDP source active messages between ISP domains and satellite domain to enable inter-domain multicast. The star topology of the conference system with the centre of the GEO OBP satellite determines the important role of the satellite NOC to be the centre of all of the MBGP and MSDP peers. To minimize the expensive satellite bandwidth requirement and the cost of end user equipment, MCUs are employed in the network to handle multimedia streams between end users and the satellite network. This paper has presented various media models that are suitable for IP conferencing over satellite. The multiple MCU model is introduced to support efficient IP conference over satellite. The Model is compatible with multicast enabled end users as well. A multicast user works as the integration of one unicast end user and one MCU. REFERENCES [1] RFC 2362: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, June [2] RFC 2858: Multiprotocol Extensions for BGP-4, T. Bates, Y. Rekhter, R. Chandra, D. Katz, June [3] IETF Internet draft: Multicast Source Discovery Protocol (MSDP), draft-ietf-msdp-spec-14.txt, D. Meyer and B. Fenner, November, 2002 (Standard track). [4] RFC 3446: Anycast RP mechanism using PIM and MSDP, Dorian Kim, David Meyer, Henry Kilmer. January [5] IETF Internet darft: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification ((Revised), draft-ietf-pim-sm-v2-new- 06.txt. B. Fenner, et al. December 2002.

5 [6] draft-ietf-idr-rfc2858bis-02.txt: Multiprotocol Extensions for BGP-4, T. Bates, Y. Rekhter, R. Chandra, D. Katz, October [7] J. Rosenberg, A Framework for Conferencing with the Session Initiation Protocol, draft-rosenbergsipping-conferencing-framework-00.txt, October [8] K.Singh, G. Nair, and H. Schulzrinne, Centralized Conferencing using SIP. In Proceedings of the 2nd IP-Telephony Workshop (IPTel'2001). April [9] Cruickshank H, Sun Z, Sanchez A and F. Carducci, Analysis of IP voice conferencing over EuroSkyWay satellite systems, IEE Proceeding on Communications, [10] J. Rosenberg and H. Schulzrine, Models for multiparty conferencing in SIP, draft-ietf-sippingconferencing-models-01.txt, July 2002.