Border Media Gateway: Extending Multimedia Multicast Gateway to Support Inter-AS Conferencing Baosong Shan, Xiangzhi Sheng and Tian Jin School of Computer Science and Engineering Beijing University of Aeronautics and Astronautics No.37 Xueyuan Rd., Haidian District, Beijing, China E–Mail: {shanbs, xzsheng, jintian}@nlsde.buaa.edu.cn.

Abstract— Lacking of high-quality links between different autonomous systems (AS) has become an obstacle to enable inter-AS multimedia conferencing. This paper presents the Border Media Gateway, which constructs inter-AS data switching channels at a host with multiple network interfaces to get higher bandwidth, lower packet loss and even lower latency between different autonomous systems. The BGW runs at the application layer and establishes channels which listen on the specified interfaces, addresses and ports. The channel examines the header information of each RTP packet to determine if it should be forwarded to the other end of the channel. BGW does not modify any RTP/RTCP packets and supports prioritized forwarding to protect important media data. Experimental results show that Border Media Gateway brings significant improvements on media quality for conferencing users from different AS.

I. I NTRODUCTION IP multicast[1] has brought great achievement for multimedia applications over Internet, such as video conferencing. But it has been poorly deployed for many technical and non-technical issues[2]. Although various kinds of multicastunicast gateway were designed to solve the problem, the total outgoing bandwidth of single gateway is limited. The ADMIRE[3] project presented the Multimedia Multicast Gateway (MMG)[3], [4] system to extend total system capacity by deploying a 2-layered gateway clusters. However, the quality of service provided by MMG is constrained by the link quality of the unicast paths between server and proxy gateways as well as between gateways and unicast users. This problem is particularly serious when the peers reside in different autonomous systems without “good” links between them. To solve this problem, we introduce Border Media Gateway, which has multiple network interfaces connecting to different autonomous systems. Thus it can build direct channels between two gateways and between a gateway and its unicast user, to replace the “bad” unicast links. The BMG works at the application layer and has the ability to understand the RTP header. This helps to realize a selectively forwarding mechanism with fine granularity scalability

1-4244-0801-6/06/$20.00 ©2006 IEEE.

to save bandwidth resource. In addition, built-in and userdefined priorities are supported to protect the important media data. The rest of this paper is organized as follows. In Section 2 we present Multimedia Multicast Gateway, which is our working basis, and an overview of the solution. Section 3 describes the Border Media Gateway in detail. Section 4 presents the experimental results on the system implementation. Some related works are discussed in Section 5. Section 6 presents the conclusion and future work. II. W ORKING BASIS AND S OLUTION OVERVIEW The work presented in this paper is based on the Multimedia Multicast Gateway, the gateway subsystem of ADMIRE, which is large-scale real-time a multimedia interactive environment system which has been used in many applications such as video conferences, science collaborations, remote interviews, remote educations, etc. In this section, we will first introduce the architecture of Multimedia Multicast Gateway, point out its limitation, and then outline our solution in a nutshell. A. Multimedia Multicast Gateway MMG is a 2-layered cascaded gateway system, as the following figure shows. Gateways on the top layer are called server gateways, which are all located within one IP multicast enabled network (usally within a LAN). The server gateways employ IP multicast to switch media data. Gateways of the bottom layer, named proxy gateways, are located on the multicast islands, with a unicast data channel connecting to a server gateway on each island. Proxy gateways on the same island, forming a cluster, also employ IP multicast to switch data, and the first one (called cluster head) has the connection up to some server gateway. Clients on a multicast island where at least a gateway (server or proxy) exists uses IP multicast to send/receive data to/from the gateway(s). Other clients has to make a unicast connection with some gateway (server or proxy). If all the users in a session either reside on the island or connect to a gateway on the same island, the cluster head does not need to forward

border connection. This solution can extend the MMG with few modifications to it. We choose it as our solution. The inserted component is called Border Media Gateway, which targets to replace the “bad” links between peers located in different autonomous systems and build inter-AS channels. A BMG benefits not only the gateways and/or users in the AS, but also those in “neighbor” autonomous systems, which means they have a better connection to it than to the former gateway cluster. The following figure illustrates the replacement.

Fig. 1.

Multimedia Multicast Gateway

the data up to its server gateway. If not, the cluster heads (at least two) must do some forwarding work according to the subscriptions, which is called Forwarding On Demands. B. Solution Overview One major limitation of MMG is the link quality of unicast connections may be very low if the peers (a server gateway and a proxy gateway, or a unicast user and a gateway) reside in different autonomous systems.

Fig. 2. Serves

Bottleneck of the Path Between a Media Gateway and a User It

As the figure above shows, the narrowest part of the whole path between the autonomous system A and B restrains the service quality provided for the unicast user. The connection quality, e.g. bandwidth and latency, on the borders of different autonomous systems is usually limited by the capacities of the devices deployed by the Internet Service Providers. On the contrast, the condition of the links inside an autonomous system is generally much better. So we think it possible to work this problem around by renting lines from the ISPs, which does not have “good” connection to the server gateway cluster, and building new “borders” ourselves. Then there are three possible solutions. First, setting up an independent server system for each rented line. No modifications need to do for this solution, but the system is segmented. Second, modifying the MMG to have the gateways work on multiple network interfaces and route packets among them. The MMG requires complicated modifications for this solution. Third, inserting a new component between the unicast-connected inter-AS pair to replace the former

Fig. 3.

BMG Replaces Default Path by Inter-AS Channels

The BMG joins (makes a connection with) the upstream host as a client and accepts the downstream host’s joining as its client. So only the administrative program, Gateway Controller, needs to be aware of the existence of BMGs and directs the two joining operations discussed above. BMGs are completely transparent for the gateways and clients, so no modifications are needed for any other programs except the Gateway Controller. The information about the connectivity and link quality between different autonomous systems, which is needed by the Gateway Controller to build inter-AS channels, is currently configured manually in the Gateway Controller. It may be possible to make use of the Border Gateway Protocol (BGP)[5] information to help build a fully dynamically intelligent routing mechanism for the modified multimedia multicast gateway system. However, since it could also make the system more complicated and even unstable, we leave it to the future investigation. III. B ORDER M EDIA G ATEWAY In this section, first we introduce the architectural design of Border Media Gateway. Then we present some features of BMG, including Forwarding On Demand and Prioritized Forwarding. And some deploying issues of BMG are discussed at the end of this section. A. The Architecture As the following figure illustrates, the BMG is a 3-layered application in logic. The Request Listener is responsible of requests receiving and parsing. The BMG accepts two kinds of requests: Message Bus (MBus)[6] messages from Gateway Controller and the manually configuration instructions from user interface. It translates the requests into internal instruction structures and passes to the Request Dispatcher. The Request Dispatcher, which has a full list of the information of all established channels, tries to find if there

channel. The requester could use this ID number to modify the SSRC list or to remove the channel. C. Forwarding On Demand

Fig. 4.

The Structure Inside a BMG

is an existing channel with the same configurations before establishing a new channel. After the channel is found or established the Request Dispatcher passes the request to it. The Request Dispatcher also maintains the running states of all the channels and provides the statistics information to the user interface. The Channels are the working components transferring data between the network interfaces. The packet statistics are done by the channel. If continuous packet loss is detected, which means the needed bandwidth exceeds the available bandwidth, the channel would drop some packets selectively according to the priority settings (see III-D). B. Channel Management Requests The Gateway Controller’s instructions are sent by MBus, which is the inter-component communicating tool of ADMIRE. Following are the requests which BMG supports. bmg.req.addchannel src_if src_ip_port dst_if dst_ip_port direct ssrc_list bmg.ack.addchannel success|failure id bmg.req.modchannel id ssrc_list bmg.ack.modchannel success|failure bmg.req.delchannel id bmg.ack.delchannel success|failure The parameter “direct” of request “addchannel” specifies the channel direction. If bi-directional is defined the sending socket also receives data from the “dst ip port” through the “dst if” and pass the data to the listening socket to send out to the “src ip port” through the “src if”. “ssrc list” specifies the list of the SSRCs demanded and their priorities (if defined) to be transferred by this channel. Since there could not be any two sources with the same SSRC, the lists do not clarify the directions of the source demanded. An SSRC with the value 0 stands for transferring all the traffic on the channel. After a request is processed and a channel is established successfully, the BMG returns an acknowledge back to the Gateway Controller with an identity number of the established

Although a BMG would not modify any packets, it can understand the RTP/RTCP protocol information in the RTP/RTCP headers, based on which, BMG supports selectively forwarding on demand. As the previous subsection describes, the request includes the demanding SSRC list. This list could be empty, however, and the BMG will only transfer the RTCP packets in that channel. In fact the RTCP packets received by the listening socket will always be transferred because they contain information which is required to maintain the session state. The SSRC “0” is often used by a audio channel since it is usually hard to understand a dialog lacking of some speakers’ voice. On the contrast, video data is less important and consumes much more bandwidth than audio. So only the requested video would be transferred. D. Prioritized Forwarding As mentioned in the previous subsection, audio usually has higher priority than video. And sometimes different users’ video have different priority as well. So the BMG would not discard the packets randomly or equally when it runs out of the network bandwidth. The priority order within a BMG is defined as follows: • All the audio data has the highest priority. • Video has a 5-level priority setting which could be defined manually, with a default priority of 3. E. Deploying Issues As we discussed above, a BMG is deployed to replace a “bad” inter-AS connection. That means there is one BMG for each connection. However, there are also several unusual special deploying modes which are listed and illustrated as follows. 1) Parallelling: Parallelled BMGs are required when we rent multiple lines from some ISP. It is also possible to set up more than one parallelled BMGs to with single line rented from each peer’s ISP. But this is usually unnecessary because processing pressure of a BMG, which only does simple forwarding without modifying any packets, is not heavy at all. 2) Multiplexing: It is also possible for a BMG to have three or even more interfaces connecting to different autonomous systems. However, further tests should be taken to ensure this will not increase the processing pressure. And an alternate way is to set up more two-way BMGs since it is economic to add hosts and switches, if necessary. 3) Relaying: Relaying is supported by BMG but is only used in the special case that if the inter A-B BMG and inter B-C BMG cannot be put together, a channel between A and C is required and, of course, it is impossible to set up a BMG directly between A and C.

IV. E XPERIMENTAL R ESULTS We have 2 hosts at the server side for this experiment. GW1 connects to the NSFCNET, and GW2 connects to both NSFCNET and the CHINANET. The experimenting client dials to the Internet with an ADSL line of CNC. First we let the client connect to either gateway using default route path and measure the loss ratio under different bandwidth settings and the average round trip time under different packet sizes. Then we deploy a BMG at the host GW2 to replace the connection between the user and GW1. Following is our experimenting results. GW

60

GW

55 50 GW

40

GW

35

GW

1 2 1 with BMG

30 25 20 15

1 2 1 with BMG

300 Round Trip Time (ms)

45 Loss Rate (%)

GW

350

250

200

150

10 5 0

100

0

100

200

300

400

500

0

200

Bandwidth (kbps)

400

600

800

1000

1200

Packet Size (Byte)

(a) Loss Rate Fig. 5.

(b) Round Trip Time Experimenting Results

We can see the default connection between the client and GW1 is poor, with a loss ratio as high as 60%, while the link quality between the client and GW2 is much better, with a loss ration lower than 3%. After we deploy our BMG, however, the connection quality between the client and GW1 has a significant improvement than before. Now let us study the performance difference between deploying two separate gateways and inserting a BMG. The average loss ratio is nearly the same and the RTT increases less than 8 ms. From the experimental results we can conclude that BMG highly improves the inter-AS link quality without importing much performance influence. V. R ELATED WORK The previous related studies most focused on the multicast connectivity problem, i.e. the availability to communicate using multicast. Unicast-multicast bridge[7] enabled unicast hosts to take part in multicast communications, and multicast tunnels (e.g. mTunnel[8]) united separate multicast islands to form a bigger multicast enabled network. Our goal, however, is to make the link quality between different autonomous systems “good” enough to support multimedia conferencing applications, which requires high bandwidth, low latency and low packet loss rate. The differences between mTunnel and BMG are listed as follows, although we think it is not suitable to compare the two since they have different design goals. • mTunnel digs tunnels between two “holes” (hosts) at either network and transfers encapsulated multicast packet between the two “holes” using unicast routing while

•

•

BMG builds channels between network interfaces within one host and does none encapsulation work. mTunnel does not need extra equipments or expenses except two hosts with the software while you may need some money to rent more “lines” from the Internet Service Providers to build the BMGs. The BMG’s channel will be much faster and wider than a multicast tunnel if the default routing path between the two networks is bad (this is true in most cases when the two networks belong to different ISPs). VI. C ONCLUSION AND F UTURE W ORK

This paper presents Border Media Gateway, an extension to the Multimedia Multicast Gateway to realize high-quality video conferencing applications among several autonomous systems with few modifications to MMG. The BMG accepts automatic configurations by Gateway Controller as well as manual configurations by an administrator. It builds broad and fast data channels to connect the inter-AS peers with the supports of the selectively Forwarding on Demand with fine granularity scalability and Prioritized Forwarding with the built-in and user-defined priority settings. The experimental use of BMG proves it is a need for the inter-AS conferencing applications. Our current work does not optimize the management protocol of MMG, which is still simple now. Further works should be done on the protocol to absorb Audio Mix Gateway [9] into MMG and make the whole system work more efficiently. ACKNOWLEDGEMENT The authors would like to thank the funding from Major State Basic Research Development Program of China (973 Program), under Grant No.2005CB321903. R EFERENCES [1] S. Deering, ““Multicast Routing in a Datagram Internetwork”,” Ph.D. dissertation, Stanford University, 1991. [2] C. Diot, B. N. Levine, B. Lyles, H. Kassem, and D. Balensiefen, “Deployment issues for the IP multicast service and architecture,” IEEE Network, vol. 14, no. 1, pp. 78–88, / 2000. [Online]. Available: citeseer.ist.psu.edu/diot00deployment.html [3] T. Jin, J. Lu, and X. Sheng, “Admire — a prototype of large scale ecollaboration platform,” Lecture Notes in Computer Science, vol. 3033, pp. 335 – 343, Jan 2004. [4] J. Tian, C. QingJi, and L. Jian, “Multimedia multicast gateway infrastructure,” in the 6th World Multiconference on Systemics, Cybernetics and Informatics (SCI 2002), Orlando, Florida, U.S.A, Jul 2002. [5] Y. Rekhter and T. Li, “A border gateway protocol 4,” IETF, RFC 1771, 1995. [6] M. Yu and X. Sheng, “Design and implementation of lightweight communication middleware mbus in component-based systems,” COMPUTER ENGINEERING AND APPLICATIONS, vol. 40, pp. 94 – 96, Oct 2004. [7] T. Cicic, H. Bryhni, and S. Sorlie, “Unicast extensions to ip multicast,” in Proceedings of the Protocols for Multimedia Systems PROMS’2000, Krakow, Poland, 2000, pp. 60–69, iSBN 83-88309-05-6. [8] P. Parnes, K. Synnes, and D. Schefstrom, “mTunnel: A multicast tunneling system with a user based quality-of-service model,” in Interactive Distributed Multimedia Systems and Telecommunication Services, 1997, pp. 87–96. [Online]. Available: citeseer.ist.psu.edu/parnes97mtunnel.html [9] T. Huang and X. Yu, “An adaptive mixing audio gateway in heterogeneous networks for admire system,” Lecture Notes in Computer Science, vol. 3033, pp. 294 – 302, Jan 2004.