V. Schena (1),F.Ceprani (1), M. Aquaviva (1), V. Brindisi (1)

Transcription

1 0XOWLSDUW\YLGHRFRQIHUHQFHWKURXJK(XUR6N\:D\VDWHOOLWHQHW ZRUNLQWKH,&(%(5*6'HPRQVWUDWRU V. Schena (1),F.Ceprani (1), M. Aquaviva (1), V. Brindisi (1) (1) Alenia Spazio S.p.A Multimedia Mission Division Via G. V. Bona Roma, Italy Tel , {v.schena, f.ceprani, m.acquaviva, $%675$&7 The present paper describes the Demonstrator Prototype developed in the Demonstrator activity framework of the ICEBERGS Project (IST ), the validation campaign execution and some important results are reported. The ICEBERGS Project aims at studying and demonstrating level the implementation and utilisation of multiparty videoconference service accessing a geo-satellite network based on the EuroSkyWay (ESW) system. Several new technical implementations characterise the ICEBERGS Demonstrator: the integration of the SIP protocol based multiparty application with MCU (Multipoint Control Unit) based entities to joint in an IP Multicast environment a group of satellite and terrestrial users; the QUASIMODO (QUAlity of ServIce-aware Multicasting Over DiffServ and Overlay networks), a new QoS methodology, coming from the GRIP (Gauge&Gate Reservation with Independent Probing) method developed and implemented in another Project (SUITED). The validation campaign has allowed to test the system in an actual situation, making available a good data quantity to perform suitable evaluations. Some interesting comments on the obtained results will conclude the paper.,'(021675$725'(6&5,37,21/$<287 $1'(17,7,(6 Fig. 1 depicts the ICEBERGS Demonstrator layout. As in the figure, three entities constitute the end-to-end Demonstrator: the remote note based on a single or a group of users (User LAN); the satellite access based on SESAT satellite positioned at 36 E and working in transparent mode at Ku band; the Demonstrator Access Network, hosting part of the major technological elements developed in the Project. 7KH 0&8 0XOWLSRLQW &RQWURO 8QLW In the ICEBERGS Demonstrator scenario both unicast and multicast users have been envisaged. The multicast terminals perform audio/video mixing or switching as needed, and the unicast users take advantage of the MCU functionalities to enter in the conferences. The multimedia data is exchanged between the multicast users and the MCUs using the large-scale multicast model. This is the preferred model because it takes advantage of the intrinsic multicast nature of ESW satellite transmission. In this model, unicast terminals send and receive multimedia streams via unicast to the MCUs that collect the streams, manipulate them and generate multicast flows that will be received by the rest of MCUs. This model minimises the bandwidth simplifying the unicast terminal requirements (no mixing/switching is needed). 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 directly through the satellite and then receive the composite signal again through the same link. For this reason, several MCUs are needed, at least one in each corporate/business or ISP (Internet Service Provider) network. For the Demonstrator one MCU for each connected sub-network is required. When a satellite terminal is considered, MCU is integrated in the E-NIU (ESW-Network Interface Unit) station. This reduces the space required by the satellite terminal, despite a major complexity of the NIU. As commercial product cannot be integrated with NIU software, a new implementation of MCU has been carried out = 6 p q 5 S T U V W T X V Y T c S d c T e f g h i W T Y S V j W T k S l d S T h Y T m n o V j e l V f h W r s r t u = > 8? ; NN [ \ ] ^ ^^ `` a a \\ ]] bb!! " " # # " " $ % $ %& &" " # # ' ' ) ) ) )" " ,, " "& /& / 0 0 $ 2$ 2 4 9? Z ;? P > ; R ; 6 p q = > 8? 7 )LJ,&(%(5*6'HPRQVWUDWRU/D\RXW N N ; 9 O 7 ; P Q 9 P 9? 8 > ; ; R ; < < C D E F F GH I J K J D E L M D

2 7KH&RQIHUHQFH6HUYHUIt manages the conference signalling. This entity is in charge of the ISPs and has to create and manage the conferences. One or more multicast addresses are allocated to the conference. The users can obtain the SIP (Session Initiation Protocol) alias of the active conferences looking in the WEB page of the conference server. To enter in the conference the unicast user has to send the invite message to the conference server using the conference SIP alias, this message is intercepted by the MCU and arrives to the conference server passing through the proxy. The MCU joins the multicast groups, and performs the conversion of the user s unicast datagrams to the multicast data flow. The multicast users can enter in the conference performing the SIP signalling with the conference server. In this case the MCU doesn t need. Multicast enabled clients belong to multicast networks. Multicast networks could be connected through nonmulticast networks. In this case a tunnelling needs between the edge router of the multicast networks. The conference server has to create and manage the conference and it is related to the ISP. The main functionalities of this entity are: create the conferences, register the conference to the registrar server, notify the status of the conference to the UA (User Agent) and perform the access control to its conferences. The ISP, using an appropriate user interface can decide the conference parameters setting the SDP (Session Directory Revised) fields and the SIP alias. When this phase is ended the conference server has to register the SIP alias to the registrar server (see Fig. 2): each conference can be seen like a multicast user v w y { } y } } ˆ Š Œ Œ Ž Œ Œ ª «0XOWLFDVW 8VHU $JHQW 0%21( 7RROV Each multicast client runs MBONE software, which is freely distributed it has been easily customised for the utilisation in the Demonstrator. MBONE (a screenshot is given in Fig. 3) hosts the following SW modules: SDR module, RAT (Robust Audio Tool), VIC (Video Conference Tool), WBD (Whiteboard) and NTE (Network Text Editor). )LJ0%21(PDLQZLQGRZVFUHHQVKRW 8QLFDVW8VHU$JHQW:LQGRZV0HVVHQJHU - For the unicast UA, Windows Messenger (a screenshot is given in Fig. 4) has been used. š œ š œ ž ž Ÿ )LJ5HJLVWHULQJDFRQIHUHQFH As the MCU also the Conference Server has been developed under Linux OS and hosted on a PC. The following software modules compose the system: A signalling handler that performs the SIP signalling to reply to the INVITE request, to perform the registration of the conferences and to manage the SUB- SCRIBE and the NOTIFY methods. The SUBSCRIBE and the NOTIFY methods are optional. An ad-hoc tool to manage simultaneously different conference. A user interface to create the conference. )LJ:LQGRZV0HVVHQJHUVFUHHQVKRW This tool to enter in a multiparty conference needs of the MCU capabilities.

3 'HPRQVWUDWRU $FFHVV 1HWZRUN Starting from the Project Study Phase outcomes, two possible scenarios have been considered for the implementation of the Access Network: 1. Full functional clients with few network elements. 2. Full functional clients with specialised SIP network elements: SIP Proxy Server, SIP Redirect Server, Location Server, Register Server and Conference Web Server. Taking into account the Project objectives, the experience coming from other EC Project and the availability of subsystem and equipment as heritage of other activities, the second solution has been considered for the Demonstrator. The multiparty videoconference takes place between users who belong to the satellite network and users connected to the terrestrial network (as in Fig. 1 depicted). The satellite link connects the users with the access network. In the access network the QoS mechanism management has been implemented having the IntServ/RSVP mechanism on the network edge (Edge Router), and the DiffServ/QUASIMODO one on the core (Core Router). SIP Proxy, Redirect, Location and Register Server allow users to communicate each other knowing only SIP addresses in a complex environment. In this case most of the complexity of the SIP protocol is managed by these entities. The Conference Servers creates the conferences and contains the Web Server where all necessary information about available conferences can be reached. As described in the initial part of the present paper, the Demonstrator foresees two different user scenarios that have been tested one at a time: remote user/sub-network (LAN of users) having satellite terminal available. Terrestrial user connected to the network by the ISPs. Considering Fig. 1, the main entities involved in the Demonstrator architecture are: 3UR[\ VHUYHU as intermediary component that stands between a SIP domain or network and Internet, it usually handle all the calls directed to a different domain or network. 5HGLUHFW VHUYHU redirecting SIP calls when the user has moved from the requested address. 5HJLVWUDU VHUYHU registering SIP clients, usually one or more servers per SIP domain are present. /RFDWLRQVHUYHU locating users, usually it bases it location on SIP registration directories, it is not very much implemented and not used by many SIP applications. &RQIHUHQFH 6HUYHU containing HTML pages with SIP alias of the available conferences. %RUGHU5RXWHUDQG&RUH5RXWHU implementing the QUASIMODO QoS mechanisms. 5HQGH]9RXV 3RLQW DQG 'HVLJQDWHG 5RXWHU implementing the multicast routing tree.,,,308/7,&$ &2/,03/(0(17$ 7,21,17+((6:6<67(0(08/$725 ESW supports the multicast protocol using a monodirectional point-to-multipoint connection replicating the cells coming from a spot beam to the destination spot beams. To establish a multiparty videoconference, each user has to open a point-to-multipoint connection with the other conference participants. In the ICEBERGS Demonstrator activity, a ESW emulator has been developed, capable to emulate a particular procedure establishing the IP Multicast connection between the videoconference participants. Since in the set-up message the unicast address of the destination user have to be specified, when the first datagram, having the IP multicast address of the destination, arrives in the E-NIU, a suitable software module establishes a correspondence between the multicast address and the unicast one for all the participants to the conference, starting in this way a point to multipoint connection set-up procedure. The procedure is executed by following steps: 1. The root (the node originating the information stream) establishes a connection with one shell, informing in the (6:B&RQQHFWLRQB3URILOHinformation element that the connection is SRLQWWRPXOWLSRLQW. 2. The root adds to the connection the additional shells using the (6:B$GGB3DUW\ procedure. All the added shells can receive the same EVCI (ESW Virtual Connection Identifier), so the information is transmitted in up-link from the root only one time and the payload emulator retransmits the information in each down-link carriers supporting the shells involved in the connection. Fig. 4 shows the information flow required to set-up a point-to-multipoint connection involving 16KHOOV To avoid a bi-directional communication between all the involved users, every E-NIU establishes a point-tomultipoint connection, so every E-NIU acts as root to transmit the local user datagram and also acts as shell to receive the information coming from the remote users. To establish the correspondence between the IP Multicast address and the IP Unicast one of the participant to the conference, the E-NIU maintains a table that is dynamically refreshed by the standard multicast routing protocol. )LJ,30XOWLFDVWWRSRLQWWRPXOWLSRLQWPHFKDQLVP,,,4R6,03/(0(17$7,21 4R6LQXQLFDVWHQYLURQPHQW*5,3VROXWLRQ- TheDemon-

4 strator Access Network layout makes available to the remote node the access to the terrestrial infrastructure, implementing and guarantying a defined quality in the access (QoS). The Access Network architecture design aims at providing the QUASIMODO QoS support adopting the so-called hybrid IntServ-DiffServ approach derived from the SUITED Project activities. The IntServ (Integrated Services) and DiffServ (Differentiated Services) architectures are the two main approaches proposed by the Internet Engineering Task Force (IETF) standardisation body to provide the Internet with QoS support capabilities. The Integrated Services architecture defines a set of extensions to the traditional best effort model of the Internet in order to provide the user applications with end-to-end QoS guarantees. The basic concept of this architecture is that the network resources have to be properly managed in order to guarantee the desired QoS needed by an application. The RSVP is the resource reservation protocol recommended by the IETF for the Integrate Services even if this architecture has been designed to accommodate also other mechanisms. Nevertheless the RSVP approach, due to its per-flow orientation and state maintenance within the network, is not scalable; therefore its usage is precluded in large-scale networks such as the Internet core network. On the other hand the DiffServ approach is based on a packet classification into a small number of aggregate flows or "classes". Each class corresponds to a different DiffServ field (DS field) set in the IP packet s header. Each DS field, in turn, is associated with a type of "network behaviour" defined between hops and called Per-Hop Behaviour (PHB). At each DiffServ router, packets are subjected to the PHB invoked by the DS field. The primary benefit of the DiffServ approach is its scalability (it eliminates the need of per-flow state and perflow processing) therefore it represents a possible alternative to the IntServ approach. The problem of the DiffServ approach is that it can t provide strict end-to-end assurance (e.g. when classes are congested). As a matter of fact, the IntServ and DiffServ can be seen as complementary technologies in the pursuit of end-to-end QoS. The goal is to exploit both the possibility for the hosts to request quantifiable resources along end-to-end data paths, provided by the IntServ approach, and the scalability properties provided by the DiffServ approach. These considerations constitute the rationale for the proposed solution for the QoS support in the ICEBERGS system that adopts the so-called hybrid IntServ-DiffServ approach. The ICEBERGS hybrid IntServ-DiffServ approach, conceptually shown in Fig. 5, foresees that the ESW access network provide QoS assurances by adopting the IntServ solution while as far as the ISPs network is concerned it is envisaged that some sub-networks adopt the IntServ approach and others the DiffServ solution. More precisely the sub-networks at the edge of the ISPs network implement the RSVP signalling protocol by means of which strict QoS guarantees can be provided, whereas in the core of the Federated ISPs network, where scalability is a stringent requirement, the scalable DiffServ model is adopted. )LJ,&(%(5*6K\EULG,QW6HUY'LII6HUYDSSURDFK IRU,34R6VXSSRUW The main issue of the hybrid IntServ-DiffServ approach is the service mapping between the IntServ and DiffServ networks; the Gateways (GW) at the edge of the core network executes this operation. Moreover, as the DiffServ approach provides distinguished and "predictable" service levels ("better than best effort" traffic) but does not provide strict end-to-end QoS assurances, in the core portion of the ISPs network in order to improve the user-perceived QoS performance an innovative solution, called GRIP, is implemented. This solution foresees that each router supports a PHB defined in terms of service priority between two classes of packets: the DF WLYH packets, which correspond to the information packets, with higher service priority and the SURELQJ packets, with lower service priority, which are delivered in order to determine if the considered connection can be admitted to the network while maintaining the QoS of the already admitted connections and of the new one. The GRIP technique allows providing KDUG JXDUDQWHHV to the admitted connections so that the user perceived performances are improved with respect to a simple DiffServ network. The implementation of the GRIP solution over the Diff- Serv network is based on the RSVP messages (RSVP messages from the source to the destination are called Path, from the destination to the source are called Resv). RSVP messages can be used as probing paths when they pass through the DiffServ network. The border routers BR1 and BR2 are the gateways at the edge of the terrestrial core network; this routers are LINUX based and they also implement the service mapping between the IntServ and DiffServ networks. The core router (CR) is LINUX based. 4R6 LPSOHPHQWDWLRQ IRU WKH,3 PXOWLFDVW 486,02'2 VROXWLRQ In the ICEBERGS Demonstrator when multicast based applications are used a mechanism compatible with the Protocol Independent Multicast Sparse-Mode (PIM-SM) is implemented, in this way when a user is added to a multicast group, only the new segment is

5 Ï Î Ä É Ä Å ÈÇÆ Å Ð probed. Fig. 6 highlights the mechanism of the implemented algorithm. Establishing the first connection (connection marked with the red line) in the core network, the GRIP mechanism starts to guarantee the QoS requirement. Asking the second user (destination 2) to receive the multicast data flow, only the new segment, marked with the blue colour, is probed. Fig. 7 shows how this )LJ0XOWLFDVW7UHHPDQDJH PHQWLQWKH'HPRQVWUDWRU implementation can be mapped in the multicast tree Fig. 8 shows the signalling exchange for the establishment of the multicast tree improved with the QUASIMODO capability.,9&21&/86,216 In the present paper the ICEBERGS Demonstrator layout has been described highlighting the main scenarios constituting the validation activity in the Project. Currently, after the first test running, the first acquired data have been elaborated demonstrating the then possibility to run the multiparty videoconference on the ESW satellite architecture, using the innovative SIP on an IP Multicast environment and participating by means the MCU also the unicast users to the multicast user groups. The innovative application of the QoS methodologies based on the QUASI- MODO methodology, are demonstrating the possibility to design a suitable access network to manage in a combined end-to-end multicast network between satellite and terrestrial accesses, a good quality service to respect the best effort available in the current global network Ë ÌÍ Ê ÇÈ Â ÃÄ ± ² ² Ð Ñ Ò Ó Ô Õ Õ Ö Ó Ø Ù Ú Û Ü Ý Þ ß Þ 100 ¹ º» ¼ ½ ¾ ¼ À ¼ Á º ¼ )LJ(VWDEOLVKPHQWRIDPXOWLFDVWWUHH )LJ6LJQDOOLQJH[FKDQJHIRUWKHHVWDEOLVKPHQWRID PXOWLFDVWWUHH )LJ2QHZD\GHOD\SHUIRUPDQFH Fig. 9 shows the results on the one-way-delay measurement carried on the end-to-end Demonstrator system, injecting background traffic by means a traffic generator (see Fig. 1) and measuring the delay between a source locate in the remote node and a destination located in the ISP.3. In the diagram it is possible to appreciate the improvement introduced by the activation of the QUASIMODO mechanism during the normal application execution. 5()(5(1&(6 [1] Project AO326, SUITED Deliverable D2, I1, System Requirements Definition Document, I1, August [2] Interworking Signalling Enhancement for H.323 and SIP VoIP ; CISCO ISO Release 12.1 (3) XI. [3] D. R. Wisel; ³6,3 DQG FRQYHUVDWLRQDO,QWHUQHW DSSOL FDWLRQV ; BT Technol, Vol 19, n. 2; April [4] ITU-T Recommendation I.350 (03/93), General Aspects of Quality of Service and Network Performance in Digital Networks, including ISDNs. [5] G. Bianchi, N. Blefari-Melazzi, Per Flow Admission Control over AF PHB Classes.